База ГОСТовallgosts.ru » 25. МАШИНОСТРОЕНИЕ » 25.040. Промышленные автоматизированные системы

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

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

Дата введения: 06/01/2017
Дата отмены: -
Заменен на: -
Код ОКС: 25.040.40, 75.020
Скачать PDF: ГОСТ Р 57323-2016 Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 11. Методология упрощенного промышленного использования справочных данных.pdf
Скачать Word:ГОСТ Р 57323-2016 Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 11. Методология упрощенного промышленного использования справочных данных.doc


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



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

57323—

2016/

ISO/TS 15926—11:2015

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

и интеграция

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

Часть 11

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

(ISO/TS 15926-11:2015, ЮТ)

Издание официальное

Стшдфттфцм

2И7

ГОСТ Р 57323—2016

Предисловие

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

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

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

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

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

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

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

© Стандартинформ. 2017

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

II

ГОСТ Р 57323—2016

Содержание

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

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

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

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

3.2    Сокращения.....................................................................3

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

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

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

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

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

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

4.6    Именованные RDF»rpa<J>bi.........................................................11

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

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

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

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

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

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

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

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

о продукции.......................................................................30

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

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

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

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

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

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

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

Приложение А (обязательное) Исходный набор взаимосвязей................................58

Приложение В (обязательное) Возможные синтаксические форматы именованных графов........59

Приложение С (справочное) Примеры применения настоящего стандарта.....................61

Приложение D (справочное) Причины представления технических данных с помощью триплетов . .65

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской Федерации...........................67

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

ГОСТ Р 57323—2016

Введение

ИСО 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, например в проекте IIP компании FIATECH. Это поможет инженерам легче понимать содержание подобных проектов.

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

IV

ГОСТ Р 57323—201 б/isorrs 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Издание официальное

1

ГОСТ Р 57323—2016

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

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

ISO/TS15926-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): Описание объекта в соответствии с описанием класса, к которому он относится, и совокупность значений свойств этот объекта.

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

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

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

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

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

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

Пример У — Определение типа документа (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-графа-триплета: граф является частью набора данных.

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

Пример — < httpU/one.exampie/subject1> < > < . example/object1> < >. # комментарии здесь.

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

2

ГОСТ Р 57323—2016

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 Сокращения

IDM — Справочник по доставке информации (Information Delivery Manual):

RDL — Библиотека справочных данных (Reference Data Library);

RDF — Среда описания ресурса (Resource Description Framework);

RDFS — RDF-схема (Resource Description Framework Schema);

SPAROL — Язык запросов к данным, представленным по модели RDF. а также протокол для передачи этих запросов и ответов на них (Protocol and RDF Query Language);

TriX — XML-триплеты (Triples in XML);

URI — Унифицированный идентификатор ресурса (Uniform Resource Identifier);

W3C — Консорциум всемирной паутины (World Wide Web Consortium).

3

ГОСТ Р 57323—2016

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-графа.

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

4

ГОСТ Р 57323—2016

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

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

Рисунок 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). который является «кондиционером

5

ГОСТ Р 57323—2016

воздуха». Таким же образом «capacity airco xyz» классифицируется как «номинальная охлаждающая способность» кондиционера. Данная информация предназначена для однозначного прочтения и понимания человеком и соответствует информации, которая обычно содержится в перечне технических характеристик. Например, мощность кондиционера «capacity airco xyz» измеряется в кВт и имеет вели* чину равную 100. Инженеры интегрируют факты, выраженные в текстовых предложениях, со всем, что они уже знают, таким образом, что в дальнейшем инженеры способны будут использовать значение, которое они получили из утверждений, предназначенных для создания новых знаний, и которые могут быть легко переданы коллегам и приведут к конкретным действиям.

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

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

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

6

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

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

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

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

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

7

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8

ГОСТ Р 57323—2016

Субъект

Предикат

Рисунок 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. применяющийся, если необходима ссылка на то. что находится вне Web-среды, используя базу идентификаторов URI, обладающую информацией об этой сущности:

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

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

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

9

ГОСТ Р 57323—2016

Пример 1 — как пример хэш URI для класса из ИСО/ТС 15926-4, который разбит на части таким образом, что первые три части являются пространством имен URI:

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

Пример 2 — Пример универсального уникального идентификатора (UUID) в соответствии с ИСО/ МЭК11578: .

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

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

•    « для идентификации конкретных сущностей проекта, где пространство имен представлено строкой символов «myprojoct:»:

•    « для идентификации концепций, взятых из ИСО 15926-2, где пространство имен « представлено строкой символов «рэ/Т2»»;

•    « для идентификации концепций, взятых из ИСО/ТС 15926-4. где пространство имен « представлено строкой символов «part#»:

•    « для идентификации взаимосвязей и типов именованных графов, где пространство имен « представлено строкой символов «рэ/Ш»;

•    « для сущностей, которые определены в частных библиотеках, где пространство имен « представлено строкой символов «library.».

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

•    «pedestal crane» (пьедестальныи кран) является подклассом класса «стало» (кран);

•    класс «crane» (кран/ имеет свойство «nominal toad weight» (номинальный вес груза/;

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

(вес):

•    свойство «nominal load weight» (номинальный вес груза/ имеет верхнюю границу «440»:

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

http

/15926/-4/tech/reference*lata RDL7459

.‘схема

■.домен

•.путь

■.фрагмент

libraryrhasProperty

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

10

ГОСТ Р 57323—2016

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

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

-    •deck crane 8710» имеет свойство •nominal load weight deck crane 8710» •номинальный вес груза палубного крана 8710»:

-    свойство •nominal load weight deck crane 8710» является экземпляром свойства •nominal load weight»:

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

-    свойству •nominal load weight deck crane 8710» присвоено значение *400».

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

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

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

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

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

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

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

11

ГОСТ Р 57323—2016

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

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

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

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

С

myprojecl:DeckCran«B710

rdf:type

mytbrary:Pedesta)Crane

\

J

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

12

ГОСТ Р 57323—2016

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

Трип пег

Субъепт

Предикат

Объект

Именованные графы UIO

myproject :DeckCraneB710

rdf:type

library:PedestalCrane

myprojectOOl

myprojectOOl

library: isCreatedBy

«John Doe»

myproject 001

myproject:001

library: isCreatedAt

«15-5-2013 12:00»

myprojectOOl

myproject DeckCraneB710

library: hasProperty

myprofect

NominalLoadWe*ght

DeckCraneB710

myproject:002

myproject:002

library: isCreatedBy

«John Doe»

myproject 002

myproject:002

library: isCreatedAt

«15-5-2013 12:11»

myproject;002

myproject:

NommaiLoadWeightDeckCraneB710

library: hasMagnitude

«400»

myprojed:003

myproject:003

library: isCreatedBy

«John Doe»

myproject 003

myproject:0Q3

library: isCreatedAt

«15-5-2013 12:15»

myproject;003

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

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

*    rdf:lype;

♦    rdf:Property;

•    rdfs:Class:

•    rdfs;subClassOf;

♦    rdfs:subPropertyOf.

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

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

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

13

ГОСТ Р 57323—2016

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

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

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

14

ГОСТ Р 57323—2016

Рисунок 9 — Пример того, как отдельный элемент «myprojectiMyCar». являющийся экземпляром транспортного средства, как это определено а библиотеке ИСО/ТС 1S926 4. соотносится с rdfs:Resource

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

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

15

ГОСТ Р 57323—2016

Рисунок 10 — Расширение RDF за счет определенного набора взаимосвязей с корневым элементом «parti ^relationship»

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

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

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

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

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

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

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

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

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

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

Примечание —Для корневого элемента «parti 1:relaUonship» действует то же самое определение, что и для сущности «relationships И СО 15926-2.

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

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

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

16

ГОСТ Р 57323—2016

constructs» (используемые структурные компоненты), все они представлены конкретным видом именованного графа:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17

ГОСТ Р 57323—2016

Y

Пример

—V"

Пример

V~

Библиотеке проектов (специализация RCH. классов и экземпляров классов)

^ Определение и ограничение взаимосвязи part и

^ Создание утверждений

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

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

18

ГОСТ Р 57323—2016

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

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

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

•    dc:creator:

•    dc:created:

•    dc:modified:

•    dc:source:

•    dc:language;

•    dc:description:

•    dc;provenance;

•    dereplaces, deisRepiacedSy.

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

•    rdfs: label;

•    rdfsidomain;

•    rdfs;range.

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

•    part11:hasReverseLabel;

•    part11:domainlsRestrictedByClass:

•    parti 1 :rangelsRestrictedByClass;

19

ГОСТ Р 57323—2016

•    part! 1 :hasModality;

•    part11:haslntention;

•    parti 1 :hasCertainty;

•    part11:hasCardina1ity;

•    part11:hasMinCardinality:

•    part11:hasMa*Cardinalily;

•    part11:hasAsBeginOfLife;

•    parti 1 :hasAsEndOfLife;

•    partt1:isModifiedBy;

•    partl1:concernsStage.

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

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

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

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

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

Рисунок 14 — Именованный граф, представляющий класс «RelationshipCIassGraph»

20

ГОСТ Р 57323—2016

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

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

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

Рисунок 16 — Именованный RDF-граф. представляющий корневой класс «рагЩ relationship»

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

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

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

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

21

ГОСТ Р 57323—2016

Рисунок 17 — Именованный RDF-грэф. представляющий место для заполнения для «МуСаг»

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

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

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

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

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

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

22

ГОСТ Р 57323—2016

dciourc*

nHs-Wwi|

rdb:tu6>repert>Of |**| partll:R«lationthipClassGraph j

I "Is pert of"

"consists of"

'Ч^й( partll:relationship

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

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

Рисунок 21 — Именованный RDF-граф. специализирующий в рамках пространства имен «myproject»

(см. рисунок 20) взаимосвязь с меткой (обозначением) «consistsOf» для взаимосвязи с меткой (обозначением)

«consistsOfPhysicaiObject»

На рисунке 22 взаимосвязь с меткой (обозначением) «has modality» (имеет модальность) из исходного набора представлена URI parti 1 ihasModatity и меткой (обозначением) «has modality» как rdfsisubPropertyOf элемента part11:relationshrp (см. рисунок 16).

23

ГОСТ Р 57323—2016

myprojpct;Adroinistratot ~*j

<k:wfw |

rdfraubPrcrertyoT P*| partll:ftdationshipOass6faph J

partll:r«tationship

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

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

Рисунок 23 — Именованный RDF-грэф. представляющий взаимосвязь part11 с мвтхой (обозначением) «is quantised in»

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

24

ГОСТ Р 57323—2016

Рисунок 25 — Именованный RDF-граф. представляющий взаимосвязь parti 1 с меткой (обозначением) «has certainty*

Рисунок 26 — Именованный RDF-граф. представляющий взаимосвязь parti 1 с меткой (обозначением) «has intention*

Рисунок 27 — Именованный RDF-граф. представляющий взаимосвязь parti 1 с меткой (обозначением) «has property»

25

ГОСТ Р 57323—2016

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

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

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

Рисунок 28 — Именованный RDF-граф. указывающий на то. что «МуСаг» является экземпляром RDL класса *part4;MotorVehide»

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

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

На рисунке 30 утверждение создано с помощью URI mypro)ect:MyCarConsistOfMyEngine и указывает на то. что myproject:MyCar состоит из myproject:MyEngine на основе предиката с URI myproject:myConsistOf.

26

ГОСТ Р 57323—2016

myproject:MyCarCon$istsOfMyEngme

dc:creator Г

myprojectJohnDoe

•1S-S-201312:50*

myprojgct:MyCar {■

-f myproject:myConsistOf

myproject:Mytngif№ J

Рисунок 30 — Именованный RDF-граф. указывающий на то. что «MyCarConsistsOfMyEngine*

(моя машина состоит из моего двигателя)

На рисунке 31 утверждение указывает на то. что myprojectMyCar имеет свойство myprojectiPowerOfMyCare. используя взаимосвязь pajt11:hasProperty.

myproject:MYCarHasPropertyPowerOfMyCar

"~~j dc:cf«ator

rdfctyp*

~1 dccraatad parti l:StatomentGraph |

myprojeetJehnOee

“15-5-2013

12:50"    |

myproj«ct:MyCar

partll:hasProporty

rnyproject :PowerOf MyCar

Рисунок 3t — Именованный RDF-граф. указывающий на то. что «МуСаг» имеет свойство «PowerOfMyCar»

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

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

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

27

ГОСТ Р 57323—2016

Рисунок 33 — Именованный RDF-граф. указывающий на то. что утверждение со свойством «PowerOfMyCan» классифицируется как номинальная мощность в соответствю с RDL классом «Nomina IPcrwer»

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

myproject:PowerOfMyCar1nsterKeDefinition2

1—»г myproject JohnOo*

"15-5-2013 12:11"

myproject:PowerOtMyCar

partll:tsQuaniffiedHi

p3it4:kW

Рисунок 34 — Именованный RDF-граф указывает на то. что утверждение со свойством myprojecfcPowerOfMyCar выражено в кВт в соответствии с RDL классом «kW»

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

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

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

28

ГОСТ Р 57323—2016

myproject:lnt«ntlonOfPowerOfMyCsrl

тур reject :MagnitudeOfPow«rOfMyCarl

part 11 :haslnton (ton

library: Proposed

Рисунок 36 — Именованный RDF-граф. указывающий на то. что утверждение о значении свойства myprojectPowerOfMyCar. равном «240». является предположением

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

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

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

Рисунок ЗВ — Именованный RDF-граф. указывающий на то. что утверждение со значением свойства PowerOfMyCar. значение которого изменено на «250», обосновано

На рисунке 39 утверждение указывает на то. что значение, равное «250». свойства myprojecfcPowerOfMyCar одобрено.

29

ГОСТ Р 57323—2016

myproject:lnt«ntionOfPow«rOfMyCar

—н_ rnyproject JohnOo«

I

ч

dcxrtmd

partll:StatementOrBph

"15-5-2013 12:50*

J

mypro ject :M agnitudeOfPow«rOfMyCar2

partll:h*slntention

library-.Approved

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

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

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

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

знаний о продукции

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

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

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

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

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

Рисунок 41 — Именованный RDF-граф. представляющий место заполнения для «РитрТурв» (тип насоса)

30

ГОСТ Р 57323—2016

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

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

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

mypro<iuct:PumpTyp«Power

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

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

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

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

31

ГОСТ Р 57323—2016

Рисунок 44 — Именованный RDF-граф. специализирующий взаимосвязь parti 1 iconsistsOf для взаимосвязи myproduct:ConsistsCHByClassOfPhysicalObject

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

partll:hasMinCardinality

1 dccreatcd

myproj«ct:Administrator

ref-type

dctourc*

"15-5-2013 12:42"

"tn"

rdfctabd

<ub»«>p»rt>o»    parti l:Re4ationshipcta«Graph

[

“has min cardinality*

parti 1 relationship

“is min cardinality for*

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

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

32

ГОСТ Р 57323—2016

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

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

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

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

Рисунок 47 — Именованный RDF-граф. определяющий myproductPumpType как подкласс класса «pump» в соответствии с ИСО/ТС 15926-4

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

Рисунок 48 — Именованный RDF-граф. определяющий myproduct:lmpe(lerType как подкласс класса «Impeller» в соответствии с ИСО/ТС 15926-4

33

ГОСТ Р 57323—2016

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

rnyproducCPumptype }

ч_____

paitil:Stat«m*nt6raph

ntyproduct:consniiOf8yClass

fflyprodiKt:lmp*llerTyp*

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

На рисунке 50 приведено утверждение, что утверждение myProduct:ProductTypeConsistsOflm petlerType имеет минимальное кардинальное число, равное двум. Таким образом, экземпляр класса myproductpumpType (с меткой (обозначением) «Pump type А») состоит, как минимум, из двух экземпляров myProduct:impellerType (с меткой (обозначением) «Impeller type В»),

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

На рисунке 51 приведено утверждение, что утверждение myproductProductTypeConsistsOflmpeil егТуре имеет максимальное кардинальное число, равное четырем. Таким образом, экземпляр класса myproductPumpType (с меткой (обозначением) «Pump type А») состоит, как максимум, из четырех экземпляров myproducUmpellerType (с меткой (обозначением) «Impeller type В»).

34

ГОСТ Р 57323—2016

Рисунок 51 — Именованный RDF-граф. указывающий на то. что экземпляр класса myproductPumpType состоит, как максимум, из четырех экземпляров my product:l mpelterTy ре «4 »

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

Рисунок 52 — Именованный RDF-граф. классифицирующий myproduclPumpTypePower как экземпляр класса «NominaPower» в соответствии с определением данного класса в ИСО/ТС 15926-4

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

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

На рисунке 54 приведено утверждение, что измерение myproductPumpTypePower. которое приводится в кВт. является произвольным со значением модальности «сап Ье» (может быть), как это определено в пространстве имен «library».

35

ГОСТ Р 57323—2016

myproduct:PumpTypePower3

rdl:typ« I

[]dc:cr«atad

partlX:StatcmantGraph J

J—*c mypro]«<t:iohnDoe ]

L-c

•15-5-20X3 X2:50"

mvprodu<t:PumpTypePewtr2 )-( partll:hatModaiity

library :CanBa

Рисунок 54 — Именованный RDF-граф. указывающий на то. что утверждение myproduci:PumpTypePower2 имеет значение модальности «сап Ье»

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

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

На рисунке 56 приведено утверждение, что измерение в лошадиных силах myproduct:PumpType Power является произвольным со значением модальности «сап Ье» (может быть), как это определено в пространстве имен «library» по отношению к именованному графу «myproduct:PumpTypePower4n.

Рисунок 56 — Именованный RDF-граф. указывающий на то. что утверждение myproducfcPumpTypePower4 имеет значение модальности «сап Ье»

36

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

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

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

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

37

ГОСТ Р 57323—2016

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

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

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

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

38

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

39

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

40

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

41

ГОСТ Р 57323—2016

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

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

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

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

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

42

ГОСТ Р 57323—2016

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

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

Серви&служба

MTBF

Состоит м (по классу) .

Тип эксплуатации

Состоит и» (по классу)

Твхнкчосхая функция

Имеет еавйстао

MTTR

Яелястоя оттаю» квешуненко

имеет ееам доп (по «лессу)

Tm предупреждетыя при эселлувтвции

Режим отказа

Имеет свойство

Имеет результатом сигнал

Имеет

Является

Является

ескееиие

Причиной для

ГрмчииОйДП»

(м r/ieccyi

(по хлеосу}

(по кпевсу)

Класс деятельности |

Тип мор безопасности |—|

Имеет ехим (по отвесу)

Тип тестовой зааа**

Олигэм е

Является причиной для (по musty)

Приводит к есхл «поео-ме

Тст 6ХОДНОЛУ

выходного сигнале

[Приводит к еоэниоювение

Тип предупреждения для техмчвекого обспуж»теэи(«

Ииоот еыю}(по тлассу)

I

Описан я

Имеет дай дпа (по классу)

Тип документа — Тип технического обслуживания

Имеет свойство

Имеет лрооолкеммв (по хлеосу)

Врамвжой ттараал выполнения

Имеет ееейстео

выполнен не (по клетоу)

Ислольауотея в

Модель производителя

Яотявтоя ипооой ««стыо дпа (по клессу)

| Специфицирований физичрсшй объект

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

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

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

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

43

ГОСТ Р 57323—2016

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

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

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

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

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

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

44

ГОСТ Р 57323—2016

Момент пересмотра

Исполнитель (рогъ)

Мьпэд шрифихаири

Статус деятельности

Исполнитель (ротъ)

Имеет свойство

Дополняете*

.яшивми.

Утверждение

Пересмотр

верифинацноттого действия

Являете» экземпляром

Имеет свойство

Является Экземпляром

Имеет статуе

Статус пересмотра

За которым следует (по классу)

исоолыувтся для проверо* (по «пасс»_

процесс

имеет статус

Верификационное

действие

Индквидг'индивидутитьмый обмят

Система

Фумин она гымй фпзичесотй сбъел

матвриализоавтыий фимяфсоат

объект

Деятегьность

Техническая функдо

лространстввжое расположение

Используется для

проверки

Спецификация требовент

Верифицирован

Состоит иэ (по «пассу}

Критерии приемки

Статус соответствия

умеет свойство

Момтт аерифихацни

Имеет область проверки

Область еерификации

Определяется

Процедура верификации

УМеетаыша

Очевидность соответствия

Имеет проблему

Проблема

Имеет место о течете

Этап мизиемюго к*<клв системы

Имеет критерий приемот

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

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

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

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

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

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

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

45

ГОСТ Р 57323—2016

Цель’эадоа

При4м<а

Учаспмк

Игкмасостсроы

Процесс

утрам оо сгсрою

Системе

Иран оо спрсш

Иимт ПрИЧМ) {по классу)

Яолпогы

0'01!?СЮР1»Х1Ш0

Документ

ОмС*н •

Ии#»» свойство

Тип последствий |

Имеет лэследстеиа (по кгоосу)

Свойства последствий

Стоимость последствии

время последствий

Качество последствий

Безопасность последствий

Экологичность последствий

Доступность последствий

Тип не посредствен xiro эффекта

Риос

Сонгропнрувтси

Управляется

Иимт эффект (по «лессу I

Имеет статус

Статус риске

Имеет свойство

Имеет свойство

вероятность

Покаэвтелъ приоритета риска

остаточный рим

Имеет е тачестее оетугьгетв

Контроль риска

Имеет статус

Смягчается

Смягчающая риск мера

Имеет е «ячестве рету/ьтата

Спецификация требований

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

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

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

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

46

ГОСТ Р 57323—2016

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

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

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

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

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

47

ГОСТ Р 57323—2016

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

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

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

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

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

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

46

ГОСТ Р 57323—2016

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

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

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

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

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

49

ГОСТ Р 57323—2016

Состоит И]

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

и взаимоотношения

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

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

ми).

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

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

50

ГОСТ Р 57323—2016

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

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

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

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

51

ГОСТ Р 57323—2016

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

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

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

52

ГОСТ Р 57323—2016

РяслроетрАммтсА

Состоит и»

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

например, посредством магистралей и кабелей

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

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

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

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

53

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

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

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

54

ГОСТ Р 57323—2016

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

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

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

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

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

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

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

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

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

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

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

Номер

колонки

Имя солонки

Содержащаяся информация

Формат

1

URI part11 Class

URt взаимосвязи

текст

2

Part 11 Class name

Предписанное имя взаимосвязи

текст

3

Reverse name

Обратное имя взаимосвязи {может использоваться приложениями для представления целей взаимосвязи в обратном направлении)

текст

4

Part 2 entity type

Тип сущности по ИСО 15926-2

текст

4

RDL class

Класс по ИСО 15926-4

текст

5

Definition

Определение класса part11 в соответствии сив контексте справочных моделей системного проектирования (см. 6.2)

текст

7

Domain

Высший класс в иерархии, который допускается на левой стороне взаимосвязи (все подклассы этого суперкласса допускаются на левой стороне)

текст

В

Range

Высший класс в иерархии, который допускается на правой стороне взаимосвязи (вое подклассы этого суперкласса допускаются на правой стороне)

текст

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

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

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

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

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

55

ГОСТ Р 57323—2016

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

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

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

Рисунок 74 — Схема рабочей температуры передатчика по ИСО 15926*2 Ниже приведена трансляция схемы, изображенной на рисунке 74. утверждения в контексте на*

стоящего стандарта:

3051CG

является специализацией

передатчика давления

3051CG

имеет свойство

рабочая температура окружающей среды

Рабочая температура окружающей среды

является специализацией

температуры окружающей среда

Рабочая температура окружающей среды

имеет в качестве нижней границы

-40

Рабочая температура окружающей среды

имеет в качестве верхней границы

85

Рабочая температура окружающей среды

рассчитывается в

Градусы Цельсия

Рабочая температура окружающей среды

имеет формат

Целое число

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

56

ГОСТ Р 57323—2016

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

Субъект

Предикат

Объект

Именованный граф UID

myproduct:3051CG

rdfs:subClassOf

mytibrary:PressureTransmitter

my product 001

myproduct:001

myproductisCreatedBy

«John Doe»

my product 001

myproduct:001

myproducbsCreatedAt

«15-5-2013 12:00»

my product 001

myproduct:3051 CG

myproducthasProperty

mytibrary:

OperaUngAmbtentTemperature

myproduct 002

myproduct:

OperatingAmbient

Temperature

rdfs:subCl3ssOf

mytibrary:

AmbientTempereture

myproduct 003

myproduct:

OperatingAmbient

Temperature

myproduct: hasAsLowerGound

«-40»

myproduct 004

myproduct:

OperatingAmbient

Temperature

myproduct: hasAsUpperGound

«85»

myproduct 005

myproduct:

OperatingAmbient

Temperature

myproduct: isQuantifiedin

mytibrary:Celstus

myproduct 006

myproduct:

OperatingAmbient

Temperature

myproduct:hasFormat

«ххх» xsd Integer

myproduct 007

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

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

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

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

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

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

57

ГОСТ Р 57323—2016

Приложение А

(обязательное)

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

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

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

http://standards.*so.org/iso/15926/-11/

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

http j'/standards.iso.org/isa’1s/15926/-3/ed-1/lech/reference-data/spread sheet/

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

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

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

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

НАБОР СПРАВОЧНЫХ ДАННЫХ ПРЕДОСТАВЛЯЕТСЯ НА УСЛОВИЯХ ПОСТАВКИ «КАК ЕСТЬ». БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ. ПРЯМЫХ ИЛИ КОСВЕННЫХ. ВКЛЮЧАЯ. НО НЕ ОГРАНИЧИВАЯСЬ ГАРАНТИЯМИ ТОВАРНОЙ ПРИГОДНОСТИ. ПРИГОДНОСТЬЮ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ И ПАТЕНТНОЙ ЧИСТОТОЙ. НИ В КОЕМ СЛУЧАЕ ИСО ИЛИ ЛЮБОЙ ДРУГОЙ ЛИЦЕНЗИАР. КОТОРЫЙ ПРЕДОСТАВЛЯЕТ ПРАВО В СООТВЕТСТВИИ С ВЫШЕУКАЗАННЫМ РАЗРЕШЕНИЕМ ИСПОЛЬЗОВАТЬ СХЕМУ. НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА КАКУЮ-ЛИБО ПРЕТЕНЗИЮ. УЩЕРБ ИЛИ ЛЮБУЮ ДРУГУЮ ОТВЕТСТВЕННОСТЬ КАК ПРИ ВЫПОЛНЕНИИ КОНТРАКТА, ПРИ ГРАЖДАНСКОМ ПРАВОНАРУШЕНИИ. ТАК И ВО ВСЕХ ДРУГИХ СЛУЧАЯХ. ВЫТЕКАЮЩИХ В СВЯЗИ С НАБОРОМ СПРАВОЧНЫХ ДАННЫХ ЛИБО В СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ИЛИ ДРУГИМИ ТОРГОВЫМИ СДЕЛКАМИ. СВЯЗАННЫМИ С НАБОРОМ СПРАВОЧНЫХ ДАННЫХ

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

ДАННЫЙ НАБОР СПРАВОЧНЫХ ДАННЫХ БЫЛ МОДИФИЦИРОВАН ПО СРАВНЕНИЮ С НАБОРОМ СПРАВОЧНЫХ ДАННЫХ. ПРИВЕДЕННЫМ В ИСО/ТС 15926-11. И НЕ ДОЛЖЕН ИНТЕРПРЕТИРОВАТЬСЯ КАК СООТВЕТСТВУЮЩИЙ ЭТОМУ СТАНДАРТУ

58

ГОСТ Р 57323—2016

Приложение В

(обязательное)

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

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

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

В.2 Формат TriX

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

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

<ТпХ>

<graph>

<uri>mypro}ectmyCarCons)StOfMyEngine </uri>

<lripte>

<uri>myprojectmyCarConsistCHMyEr>gire</uri>

<uri>dc:creator</uri>

<uri>myproject JohnDoe</uri >

</tripie>

<trip*e>

<uri>myprojectmyCarConsistOIMyEngine</uri>

<uri>dc:created</uri>

<typedLitera> datatype='xsd:dateTime" > 2013-05-5T12;00;00Z < /typedliterat >

</tripte>

<tripte>

<uri>mypro»ect:myCarConsist01MyEng«ne</uri>

<uri>rdf:type</uri>

<uri>part11 :StatementGraph</uri>

</tripie>

<trip*e>

<uri>myproject:MyCar</uri>

<uri>myproject:MyEngine</uri>

</tnpte>

</graph>

</TriX>

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

Формат N-Quads является стандартом W3C. который определяет легкий для парсинга текстовый язык кодирования наборов RDF-данных (см. ).

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

59

ГОСТ Р 57323—2016

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

URI субъекта

URI взаимосвязи

URI объекта

URI именованного графа

myproject:MyCarConsist

OfMyEngine

dc:creator

MyprojectJohnDoe

myproject:MyCarConsistOfMy

Engine

myproject:MyCarConsist

OfMyEngine

defeated

myproject:MyCarConsistOfMy

Engine

myproject:MyCarConsist

OfMyEngine

rdf:type

myproject:MyCarConsistOfMy

Engine

myprofectMyCar

myproject:myConsistOf

myproject:MyCarConsistOfMy

Engine

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

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

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

URI субъекта

Имя

субъекта

URI

взаимосвязи

Иыя

взаимосвязи

URI

объекта

Имя объекта

URI именованного трефа

myproject:

MyCarConsist

OfMyEngine

dc:creator

создано (автор)

(is created by)

Myproject

JohnDoe

JohnDoe

myproject:

MyCarConsist

OfMyEngine

myproject

MyCarConsist

OfMyEngine

dc:created

создано

(время)

(is created at)

«2013-05-

15Т12.00:00»

myproject:

MyCarConsist

OfMyEngine

myproject

MyCarConsist

OfMyEngme

rdf:type

является типом (is of type)

StatementGraph

myproject:

MyCarConsist

OfMyEngine

myproject:MyCar

MyCar

myproject

myConsistOf

состоит из (myConsistOf)

myproject:

MyEngine

MyEngine

myproject:

MyCarConsist

OfMyEngine

60

ГОСТ Р 57323—2016

Приложение С

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

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

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

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

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

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

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

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

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

61

ГОСТ Р 57323—2016

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

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

Субъект

Взаимосвязь

Имеет

кардинальность

Объект

Имеет

модальность

система отопления (healing system)

состоит из (consist of)

<1>

теплообменник (heat exchanger)

должен иметь (shall have)

теплообменник (heat exchanger)

является исполнителем (is performer of)

теплообмен между двумя потоками (exchanging heat between two streams)

первичный поток (primary stream)

участвует 8 (participates in)

теплообмен между двумя потоками (exchanging heat between two streams)

вторичный поток (secondary stream)

участвует e (participates in)

теплообмен между двумя потоками (exchanging heat between two streams)

переичный поток (primary stream)

является материалом из (is material of)

масло-теплоноситель (thermal oil)

должен иметь (shall have)

вторичный поток (secondary stream)

является материалом из (is material of)

горячая вода (hot water)

должен иметь (shall have)

теплообменник (heat exchanger)

состоит из (consist of)

система насоса (pump system)

должен иметь (shall have)

система насоса (pump system)

состоит из (consist of)

насос

(pump)

должен иметь (shall have)

система насоса (pump system)

состоит из (consist of)

трубе

(pipe)

должен иметь (shall have)

система насоса (pump system)

является исполнителем (is performer of)

подача горячей воды к центральным аппаратам кондиционирования воздуха (providing hot water to central air handling units)

должен иметь (shalt have)

насос

(pump)

является исполнителем (is performer of)

циркулирующий вторичный поток (circulating secondary stream)

должен иметь (shalt have)

насос

(pump)

имеет свойство (has property)

мощность насоса (pump capacity)

должен иметь (shalt have)

мощность насоса (pump capacity)

квалифицируется как (is qualified as)

50 % полной мощности системы отопления (50 % of the full heating system capacity)

должен иметь (shalt have)

первичный лоток (primary stream)

находится под ответственностью (is the responsibility of)

клиент

(client)

62

ГОСТ Р 57323—2016

Окончание таблицы С.1

Субъект

Взаимосвязь

Имеет

кардинальность

Объект

Имеет

модальность

вторичный поток (secondary stream)

находится под ответственностью (is the responsibility of)

контрактор

(contractor)

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

совместно с неструктурированными данными в документах

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

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

•    файла информационной модели, испотъзующего методологию именованного графа настоящего стандарта:

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

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

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

/

г--"

....._

| Зэголсеос

Ч._.................

3wweee**w Beiin

С»Оье«т

Прайме*

Объел

1М1>)теерни'^«~

«сапл>«ла01

WHTOHWWI

«>^(«агг>са» caffttyHi»

мвмшвтес1

ммегмюы

иа*реегенфм»р

авмпаия* XY2

itatemcnttC?

шмгалши

аалейаланМымы

11-2-2013 13 М 12

«ШхгелВСЗ

statecrenMOl

MAN**

«чмпьи насоеЯБС

MatetrenttC-l

НМЫ 14—11

шалг си ящ

«аЫг«пМС->

еыееггегМЯ

1мм*ф|»а4мм»

ШЙМКИО

•Швгг-епМСб

нем.......

•мает стбъагт

снсшмо

емепешесг

Предел веление семантического слов (передано через ВИА. •онтеОмер. например 21Р-файп|

\

Р* «аапмодат 1

С>бъект

Поедим?

Сбъап

uiO-утааркданм

пюхлгм>р<в*<о*№лм >

чЮ»

etupowian снетки

яаилилвЮЮЭ

вмЮИММЮСГМ!

на» Hi<ii4Poaai

<03

WWIWW3101

ваксл» «монетка

fIMVfilMM

3DTBC0O.F.01 ------

ёвйЗВВТЗГ

UTEK0CC41

аапиок» типом

R0C4P4O

ММПОТЯ0103

гицсию— «амспжхи емтоивг

на> киечмооааи

1 $3300-34

яаипилмкн

1 $33-0044

мпмтс* тилем

R0C444BS-O9C*

sUNmentMIOS

нмое ага пи iOii аак 1

■отии «мсом

Маоосага гриден «ж

■мгпепиемм

навое are памноАаовм

мгметс* тилем

RDUeom»

eWemenWOlOT

наем «па гечиЫ асом

ошювкжа».

SJftAPWSS-POS

kMBIIBPQ1Ue

ЗЗЯАРЭДЬО-ОЗ

ш+йк ■ тилем

RCXMtta-M*«0

KMemoree0109

«mrcMiMlM

Oeemieaew «еают»сн

мметегааопо

TlgfMMB» 1 и) tBPWtM

Ш+ЛК» ТИЛОМ

Пеоктмаа даятамньсть

мемлМШ

навое дгмпмвиоАеой» <

шжтФпневаы

«ЗЗНКР101

eeewrwnwoiiz

-U.W101

оалйвгс* типом

ЯОшаопоте

илишанчОПЗ

ивеведгнфакоаваем >

наьеефнмеевы

132 3 4

awiamanwoiH

1S 234

«впиете* шлем

ROUSBS-coda

иаытчт»оП5~

иаоосдгечжыаоеы ■

О0СГЦЛ01И1>

■Же iohnkw fansM1

ЯааателИОПб

••«►H0102

1>ггг •f>nrrf<n п.шыт*х

—㻈тс* тилем

Теюадеава (вмашаииа

1

—ЯНР102

ошка

•GUO iFCiboee*---*'"

Ьималммюи» 1

“Х

Г

It

i

и

я

эотекоо-е-91

_____У -

мяавамарю

!| до»>мем»агы*э« честь 8>М-<ентейнера

модельная част» В'М-«0иге**ерв

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

63

ГОСТ Р 57323—2016

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

жизненного цикла продукции

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

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

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

■ Колонка 4е: URI имвнокымото графе ]

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

64

ГОСТ Р 57323—2016

Приложение О

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

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

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

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

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

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

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

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

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

Объект с левой стороны (RDF.субъект)

взаимосвязь (RDF предикат}

Объект с правой стороны {RDF:o6b«KT)

Машина

является подтипом

транспортное средство

Колесо

может быть частью

машина

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

65

ГОСТ Р 57323—2016

Рисунок D.1 — Взаимосвязь между Geilish и RDF На рисунке D.2 проиллюстрирован факт на языке GelSsh.

•    предезмэдн*

>    примерность >ст*ту«

>    истотик

•    прояснен*

•    lO-Rpoeonpitewma

Мега-данные утверждежя

- соиатег*»

•    дета создания 'чздатмость

•    дата поепяднега мнямеиия

•    язык

Ю-факта Объект с левой стороны

Индивидуальный объект или слоиртмй термин

Отношение

Факт

Объест с правой стороны

Индивидуальный объект, словарный термин или значение

Fact ID 1

Палубный край

Является типом

Термины, определенные в словаре

\\*4'' Кран

2

Палубный кран

Имеет свойство

\ \ вес нагрузки

3

Вес груза

Является типом

\ ' Собственный вес

4

Вес груза

Имеет величину

\ 400

6

Вес груза

Рассчитывается в

\ Тонны

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

66

ГОСТ Р 57323—2016

Приложение ДА

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

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

Таблица ДА.1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и намменоеоиие соответствующего национальною стандарта

1SCWTS 15926-4

ЮТ

ГОСТ Р 55340—2014/ISCVTS 15926-4:2007 «Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий. включая нефтяные и газовые производственные предприятия. Часть 4. Исходные справочные данные»

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

- ЮТ — идентичный стандарт.

67

ГОСТ Р 57323—2016

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

[1]    ISO 704:2009 Terminology woric. Principles and methods (Терминологическая деятельность. Принципы и методы)

[2]    ISO 80000-1:2009 Quantities and units. Part 1: General (Величины и единицы. Часть 1. Общие положения)

[3]    ISO 8000-2:2012 Data quality. Part 2: Vocabulary (Качество данных. Часть 2. Словарь)

[4]    ISO 10303-1:1994 Industrial automation systems and integration. Product data representation and exchange. Part 1: Overview and fundamental principles (Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 1. Обзор и основные принципы)

[5]    ISO 10303-221:2007 Industrial automation systems and integration. Product data representation and exchange. Part 221: Application protocol: Functional data and their schematic representation for process plants (Системы промьяипенной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 221. Протокол прикладной программы. Функциональные данные для технологических установок и их схематическое представление)

[6]    ISO 10303-233:2012 industrial automation systems and integration. Product data representation and exchange. Part 233: Application protocol: Systems engineering (Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 233. Протокол прикладной программы. Системотехника)

[7]    ISO/1EC 11578:1996 Information technology. Open Systems Interconnection. Remote Procedure Call (RPC) (Информационные технологии. Взаимодействие открытых систем. Вызов удаленных процедур)

[8]    ISO/1EC/IEEE 15288:2015 Systems and software engineering. System life cycle processes (Проектирование систем и разработка программного обеспечения. Процессы жизненного цикла системы)

[9]    ISO 15926-1:2004 Industrial automation systems and integration. Integration of life-cycle data for process plants including oil and gas production facilities. Part 1: Overview and fundamental principles (Системы промышленной автоматизации и интеграция. Интеграция данных о сроке службы нефтехимических установок, включая установки по добыче нефти и газа. Часть 1. Общее представление и основные принципы)

[10]    ISO 15926-2:2003 Industrial automation systems and integration. Integration of life-cycle data for process plants including oil and gas production facilities. Part 2: Data model (Системы промышленной автоматизации и интеграция. Интеграция данных о сроке службы нефтехимических установок, включая установки по добыче нефти и газа. Часть 2. Модель данных)

[11]    ISO/TS 15926-6:2013 Industrial automation systems and integration. Integration of life-cycle data for process plants including oil and gas production facilities. Part 6: Methodology for the development and validation of reference data (Системы промышленной автоматизации и интеграция. Интеграция данных о сроке службы нефтехимических установок, включая оборудование и сооружения для добычи нефти и газа. Часть 6. Методология разработки и валидации справочных данных)

[12]    ISO/TS 15926-7:2011 Industrial automation systems and integration. Integration of life-cycle data for process plants including oil and gas production facilities. Part 7: Implementation methods for the integration of distributed systems: Template methodology (Системы промышленной автоматизации и интеграция. Интеграция данных о сроке службы нефтехимических установок, включая оборудование и сооружения для добычи нефти и газа. Часть 7. Методы исполнения объединения распределенных систем. Методология шаблонов)

[13]    ISO/TS 15926-8:2011 Industrial automation systems and integration. Integration of life-cycle data for process plants including oil and gas production facilities. Part 8: Implementation methods for the integration of distributed systems: Web Ontology Language (OWL) implementation (Системы промышленной автоматизации и интеграция. Интеграция ванных о сроке службы нефтехимических установок, включая оборудование и сооружения для добычи нефти и газа. Часть 8. Методы исполнения объединения распределенных систем. Внедрение сетевого онтологического языка)

[14]    W3C:2014: Структура описания ресурсов (RDF) Версия 1.1:

[15]    W3C:2014; Именованные графы

[16]    Ссылка на язык OWL веб-онтологии. W3C Рекомендация 2004-02-10. Имеется во Всемирной сети Интернет (WWW):

[17]    Berners-Lee T. Cool URIs don't change. Имеется во Всемирной сети Интернет (WWW):  cooluris/

68

ГОСТ Р 57323—2016

[18]    Geilish. Общий расширяемый онтологический язык — Конструкция и применение Универсальной структуры данных, д-р. 1г. Andries van Renssen. ISBN 904072597-7. Пресса Политехнического института в Депфте. 2005: httpyAATArw.gellish.net/downloads {pdf} или httpy/ (печатная копия)

[19]    ИСО/ТК 184/ПК 4 № 2265. Унифицированный идентификатор ресурса (URI). определяемый с помощью стандарта ПК 4

[20]    ИСО/ТК 184/ПК 4/РГ 1 doc.3.2.2.1. Общая справочная модель АЕС (GARM). отчет TNO BI-88150. октябрь 1988

[21]    Дублинский набор основополагающих элементов метаданных. Версия 1.1 hltp://dub(incore.org/ docucnents/2012/06/14/dces/

69

ГОСТ Р 57323—2016

УДК 658.52.011.56    ОКС 25.040.40, 75.020

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

Редактор А.Е. Петросян Технический редактор В.Н. Прусакова Корректор ЕЛ. Дульчева Компьютерная верстка Е.А. Кондрашовой

Сдано в набор 14.12.2016. Подписано в печать 15.02.2017. Формат 60*64%. Гарнитура Ариал. Уел. печ. л. 6.37. Уч.-им. л. 7.54.    Тираж 26 экз. Зак 357.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ*. 12399S Москва. Гранатный пер.. 4.