Полное меню
- Актуальное
законодательство - Интернет
и право- - Рассылка ''Закон есть закон''
- - Форум сайта (архив)
- - Законодательство
- - Судебная практика (необычная)
- - Судебная практика (авторская)
- - Процедура UDRP и и решения WIPO
- - Книги серии ''Интернет и Право''
- - Книги в открытом доступе
- - Учебный курс ''Интернет и Право''
- - Учебный курс ''Доменные споры''
- - Литература по ''Интернет и Право''
- - Литература по интел. собственности
- - Научный уголок (работы гостей)
- - Авторские публикации
- Информационные
материалы - ЮРИДИЧЕСКИЕ
УСЛУГИ- - Перечень юридических услуг
- - Карта юридических услуг
- - Юридическая консультация
- - Доменные споры (RU), авторское право
- - Международный суд по доменам (COM)
- - Защита прав на маркетплейсе (WB, Ozon)
- - Защита прав в соцсетях (Vk, Ok, FB)
- - Купля-продажа домена, сайта, ПО
- - Досудебное урегулирование конфликта
- - Защита чести и деловой репутации
- - Отмена блокировки сайта/домена РКН
- - ФАС: товарные знаки, авторское право
- - Регистрация ПО/сайта (Роспатент)
- - Юридическая проверка домена
- - Нотариальное заверение сайтов
- - Способы и формы оплаты услуг
- - Мы в СМИ
- - О компании, клиенты
- - Наши дела и победы
- - Контакты и реквизиты
- Информация
о сайте -
ОписаниеИсточник публикации М.: Стандартинформ, 2017 Примечание к документу Документ введен в действие с 1 июня 2017 года. Название документа "ГОСТ Р 57323-2016/ISO/TS 15926-11:2015. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 11. Методология упрощенного промышленного использования справочных данных" (утв. и введен в действие Приказом Росстандарта от 06.12.2016 N 1952-ст) "ГОСТ Р 57323-2016/ISO/TS 15926-11:2015. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 11. Методология упрощенного промышленного использования справочных данных"
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Объект (выполняющий роль 1) | Взаимосвязь | Объект (выполняющий роль 2) | ||
airco xyz | Классифицируется как | Кондиционер воздуха | ||
airco xyz | Имеет свойство | Мощность airco xyz | ||
Мощность airco xyz | Классифицируется как | Номинальная охлаждающая способность | ||
Мощность airco xyz | Измеряется в | кВт | ||
Мощность airco xyz | Имеет значение равное | 100 | ||
о продукции в формате утверждения
В то время как используемые RDF-утверждения (модели данных, выраженные в формате триплетов) просты и легки для понимания, упорядоченное представление имеет высокую сложность для визуализации полной структуры знаний и ее передачи коллегам. Графическое представление RDF-утверждений в данном случае имеет целью помочь инженерам, поскольку RDF также устанавливает стандартный способ представления графов утверждений, их совместное использование в on-line и/или off-line режимах. Дальнейшие онтологии дают возможность инженерам осуществить логический вывод правил на основе утверждений. Инженеры могут совместно использовать свои онтологии с коллегами, но они должны обладать полным набором знаний, чтобы сделать определенные логические выводы из имеющихся в их распоряжении утверждений. То же самое будет верно и для компьютерных систем, если им предстоит обмениваться теми же онтологиями.
Оба объекта в утверждении имеют конкретные роли, относящиеся к значению во взаимосвязи. По этой причине утверждение всегда должно быть читаемым в двух направлениях, слева направо и справа налево. Таким образом, каждая взаимосвязь, определенная в исходном наборе, имеет два имени: "предписанное" имя, считываемое с объекта, выполняющего роль 1, и объекта, выполняющего роль 2, и резервное имя, считываемое с объекта, выполняющего роль 2, на объект, выполняющий роль 1 (airco xyz имеет роль 1 и capacity airco xyz имеет роль 2 в части взаимосвязи). Обратные утверждения для утверждений, приведенных на рисунке 2, представлены на рисунке 3.
Объект (выполняющий роль 2) | Взаимосвязь | Объект (выполняющий роль 1) | ||
Кондиционер воздуха | Является классификацией для | airco xyz | ||
Мощность airco xyz | Является свойством | airco xyz | ||
Номинальная охлаждающая способность | Является классификацией для | Мощность airco xyz | ||
кВт | Является измерением для | Мощность airco xyz | ||
100 | Является значением величины | Мощность airco xyz | ||
Рисунок 3 - Утверждения, приведенные на рисунке 2,
представленные в обратном направлении
для представления утверждений
Одним из преимуществ использования утверждений является то, что любой желающий может с использованием одной и той же методологии описать любые модели продукции и создать данные экземпляра (модели) в репозитории, а также организовать обмен данными между сторонами и/или системами управления конфигурациями.
В контексте технических данных существует потребность в создании утверждений об утверждениях. Такая возможность может быть реализована путем идентификации каждого утверждения с помощью уникального идентификатора. По этой причине каждое утверждение дополняется Унифицированным идентификатором ресурсов (URI). Путем обращения к конкретному URI любое заинтересованное лицо может создать утверждение об утверждении, которое представлено данным URI.
Пример - Примером утверждения об утверждении является утверждение о времени, когда некоторое лицо заявило о конкретном утверждении.
Если различные стороны в промышленности взаимодействуют между собой (обмениваются утверждениями), то в целом возникает потребность в подробных утверждениях об утверждениях. Эти утверждения об утверждениях поддерживают рабочий поток данных о промышленной обработке по всей цепочке поставок. Помимо данных об источнике происхождения существуют фундаментальные требования к процессам электронного обмена, обращения к конкретным элементам/объектам и архивирования промышленных данных.
Для упрощения процессов обмена техническими данными и выполнения транзакций общепризнанными являются следующие утверждения об утверждениях:
- создатель (автор) утверждения (участник или роль);
- дата и время создания утверждения;
- участник или роль, внесшая изменение в утверждение;
- дата и время изменения утверждения;
- достоверность утверждения; возможные значения (экземпляры) для определения достоверности, которые могут быть "оценены", "рассчитаны" или "заданы изначально" (as-build); должна иметься возможность классифицировать вероятности корректных величин значений для значений свойств;
- модальность утверждения; возможные модальные словосочетания для выражения модуса утверждения: могут использоваться следующие возможные величины (экземпляры) модальности, например "может быть", "должен быть" и "должен иметь", поддерживающие управление требованиями и моделирование знаний о продукции. Значением по умолчанию модуса утверждения будет "является случаем" (is the case);
- назначение утверждения, возможные значения (экземпляры): "запрашиваемый", "предполагаемый", "одобренный". Поддерживающие рабочий поток (workflow) в процессе обмена и при управлении изменениями, особенно для значений характеристик;
- мощность множества элемента (применяется для "объекта, выполняющего роль 2") для утверждений, поддерживающих управление требованиями и моделирование знаний о продукции;
- управление версиями утверждений, поддерживающее библиотеку версий и метод сравнения с базовыми, ранее установленными значениями (base lining) в контексте управления конфигурацией;
- отнесение утверждений к жизненному циклу конкретной системы и разграничение информации, которая является существенной для концептуального проектирования, технического проектирования или стадии сопровождения системы;
- определение таких понятий для утверждений, как "начало жизни" (begin of life) и "конец жизни" (end of life), чтобы можно было определить период времени, с какого момента конкретное утверждение действительно.
Данный метод может определять схемы, а также экземпляры схемы, определенные в нейтральном формате, и может быть реализован на любом синтаксическом слое, например крупноформатная таблица, XML и т.д. (см. приложение B).
Среда описания ресурсов (RDF) является формальным языком Консорциума W3C, который позволяет описывать семантику информации таким же образом, как и механизм утверждений, описанный в 4.3. RDF является универсальным языком; изначально он предполагался для представления информации в Web-среде. Он определяет язык для описания взаимосвязей между ресурсами в виде именованных свойств и величин. Свойства в контексте RDF являются экземплярами класса rdf:Property и описывают взаимосвязь между ресурсами субъекта (левая сторона взаимосвязи, элемент с ролью 1 утверждения) и ресурсами объекта (правая сторона взаимосвязи, элемент с ролью 2 утверждения). При таком использовании свойство является предикатом в контексте RDF.
RDF не предоставляет механизмов описания свойств, а также механизмов описания взаимосвязей между свойствами и другими ресурсами. Данные средства предусмотрены RDF-схемой (языком RDFS), которая содержит набор классов и свойств для модели представления знаний RDF, составляющий основу для описания онтологии с использованием расширенного RDF-словаря для структуры RDF-ресурсов. Эти ресурсы используются для определения характеристик других ресурсов, таких как домены и диапазоны свойств. Описания RDFS-словаря написаны на языке RDF.
Большинство абстрактных моделей RDF сводится к четырем простым правилам:
- утверждение выражается в виде триплета Субъект-Предикат-Объект: аналогично (краткому) предложению на английском языке;
- субъекты, предикаты и объекты представляются в виде имен для сущностей, также называемых ресурсами (возвращаясь назад к применению RDF для метаданных web-ресурсов) или узлами (из терминологии графов): эти сущности представляют собой объекты, например индивидуумы, веб-сайты или что-то более абстрактное, например состояния или взаимосвязи;
- имена представляют собой унифицированные идентификаторы ресурсов (URIs), которые являются глобальными по области охвата и всегда относящимися к одному и тому же элементу в любом документе RDF, в котором они используются;
- объекты также могут быть представлены в виде текстовых величин, называемых литеральными значениями, которые могут быть, а могут и не быть напечатаны с помощью типов данных XML-схемы.
Простота и гибкость триплетов в комбинации с использованием унифицированных идентификаторов ресурсов для глобально уникальных имен субъектов, предикатов и объектов делает 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 ссылка (абсолютная форма) состоит из трех частей: схемы, конкретной иерархической части схемы и фрагментного идентификатора.
Пример 1 - /template/go.php?url=https://standards.iso.org/iso/15926/-4/tech/reference-data#RDL7459 как пример хэш URI для класса из ИСО/ТС 15926-4, который разбит на части таким образом, что первые три части являются пространством имен URI:
http :схема
/template/go.php?url=https://standards.iso.org/iso :домен
/15926/-4/tech/reference-data :путь
RDL7459 :фрагмент
Для фрагментарной части именованного графа предпочтительно используется универсальный уникальный идентификатор (см. ИСО/МЭК 11578).
Пример 2 - Пример универсального уникального идентификатора (UUID) в соответствии с ИСО/МЭК 11578: /template/go.php?url=https://example.com/myproject#40bb99c0-1f74-11e2-81c1-0800200c9a66.
Примечание 1 - Для именования объектов и написания составных слов в настоящем стандарте используется методика CamelCase. При написании взаимосвязей каждое составное слово начинается со строчной буквы. Любой объект, не являющийся взаимосвязью, начинается с заглавной буквы, а взаимосвязи начинаются со строчной буквы.
В настоящем стандарте используются следующие пространства имен:
- "www.example.com/myproject#" для идентификации конкретных сущностей проекта, где пространство имен www.example.com/myproject#" представлено строкой символов "myproject";
- "www.example.com/part2#" для идентификации концепций, взятых из ИСО 15926-2, где пространство имен "www.example.com/part2#" представлено строкой символов "part2";
- "www.example.com/part4#" для идентификации концепций, взятых из ИСО/ТС 15926-4, где пространство имен "www.example.com/part4#" представлено строкой символов "part4";
- "www.example.com/part11#" для идентификации взаимосвязей и типов именованных графов, где пространство имен "www.example.com/part11#" представлено строкой символов "part11";
- "www.example.com/library#" для сущностей, которые определены в частных библиотеках, где пространство имен "www.example.com/library#" представлено строкой символов "library:".
Пример 3 - На рисунке 5 показан пример набора графов, который является набором утверждений о спецификации свойства "nominal load weight" (номинальный вес груза) типового пьедестального крана, включая классификацию пьедестального крана. Используется пространство имен "library:". На рисунке 5 представлены следующие утверждения:
- "pedestal crane" (пьедестальный кран) является подклассом класса "crane" (кран);
- класс "crane" (кран) имеет свойство "nominal load weight" (номинальный вес груза);
- свойство "nominal load weight" (номинальный вес груза) является подклассом свойства "weight" (вес);
- свойство "nominal load weight" (номинальный вес груза) имеет верхнюю границу "440";
- свойство "nominal load weight" (номинальный вес груза) измеряется с помощью единицы измерения "tonnes" (тонны).
Пример 4 - На рисунке 6 показан пример набора графов, который представляет собой набор утверждений о спецификации свойства "nominal load weight" типового пьедестального крана (пьедестальный кран B710, являющийся индивидуальным объектом) в качестве его инстанцирования. Экземпляры определены на пространстве имен "myproject:", классы определены на пространстве имен "library:". На рисунке 6 представлены следующие утверждения:
- "deck crane B710" (палубный кран B710) является экземпляром "пьедестального крана";
- "deck crane B710" имеет свойство "nominal load weight deck crane B710" "номинальный вес груза палубного крана B710";
- свойство "nominal load weight deck crane B710" является экземпляром свойства "nominal load weight";
- свойство "nominal load weight deck crane B710" измеряется в "tonnes" (тоннах);
- свойству "nominal load weight deck crane B710" присвоено значение "400".
"номинальный вес", как это определено на рисунке 5
Примечание 2 - Прикладное программное обеспечение поможет проверить, вписывается ли величина "400", используемая на рисунке 6, в заданную верхнюю границу "440", определенную в типовом классе "Pedestal Crane", приведенном на рисунке 5.
Именованные графы являются ключевой концепцией архитектуры Семантической паутины Semantic web, в которой набор RDF (RDF-триплетов) утверждений (граф) идентифицирован с помощью уникального URI. Таким образом, утверждение может выборочно сопровождаться дополнительной информацией. Это необходимо для того, чтобы можно было точно определить характеристики, контекст или метаданные утверждения.
Пример 1 - Примером информации, явным образом сопровождающей утверждение, является предназначение конкретного утверждения, которое заявляет, что утверждение востребовано, предложено или одобрено.
Именованные графы являются небольшим расширением абстрактного RDF-синтаксиса. Именованные графы дают возможность рассуждать об RDF-графах с помощью RDF-утверждений (другими словами, позволяют создавать утверждения об утверждениях). Метаданные утверждения, например ресурс, лицо, вносящее изменение, информация об изменении, контекст, могут быть выражены в виде триплетов, принадлежащих утверждению. Эти дополнительные триплеты однозначно принадлежат триплету, который представляет собой утверждение. Поэтому в настоящем стандарте используется W3C-версия именованных RDF-графов. Помещая триплет "main" (главного) утверждения в именованный RDF-граф, любое требуемое количество дополнительных триплетов может указывать на первый триплет, представляющий собой метаданные.
Пример 2 - Конкретное утверждение может определять количество элементов (кардинальное число) объекта, содержащегося в другом конкретном утверждении.
Пример 3 - Конкретное утверждение может определять достоверность значения свойства, которая определяется как значение величины свойства в другом конкретном утверждении.
Концепция именованных RDF-графов обеспечивает гибкость при моделировании продукции и производственных объектов. Также эта концепция дает возможность представлять любой рабочий процесс или процесс создания продукта в виде графа, что облегчает извлечение требуемых предикатов (эквивалент взаимосвязи). Этот метод применен для процесса ИСО/МЭК 15288 с целью определения утверждений субъекта, предиката и объекта таким образом, что стало возможным внести аспект проектирования систем в среду ИСО 15926.
Пример 4 - На рисунке 7 приведен пример с тремя именованными графами, представляющими собой три утверждения, указанные на рисунке 6. Первый именованный граф указывает на то, что DeckCraneB710 (ПалубныйКранB710) является экземпляром класса "PedestalCrane" ("ПьедестальныйКран"). Второй именованный граф указывает на то, что экземпляр класса DeckCraneB710 имеет свойство "NominalLoadWeightDeckCraneB710" ("НоминальныйВесГрузаПалубногоКранаB710") и третий именованный граф указывает на то, что этому свойству присвоено значение равное "400". Каждый триплет сопровождается метаданными типа "isCreated by" ("Создан, указание на создавшее лицо"), "isCreated at" ("Создан, указание на дату/время") и "isModifiedAt" ("Изменен, указание на дату/время").
Примечание - С целью удобства для чтения именованные графы в примерах, используемых в настоящем стандарте, имеют логические имена, а не формальный UIDD.
для триплетов, приведенных на рисунке 6
В таблице 1 именованные графы, показанные на рисунке 7, записаны в формате N-Quad W3C.
Таблица 1
Представление именованных графов в формате N-Quad W3C
Триплет | |||
Субъект | Предикат | Объект | Именованные графы UID |
myproject: DeckCraneB710 | rdf:type | library:PedestalCrane | myproject: 001 |
myproject: 001 | library: isCreatedBy | "John Doe" | myproject: 001 |
myproject: 001 | library: isCreatedAt | "15-5-2013 12:00" | myproject: 001 |
myproject: DeckCraneB710 | library: hasProperty | myproject: NominalLoadWeight DeckCraneB710 | myproject: 002 |
myproject: 002 | library: isCreatedBy | "John Doe" | myproject: 002 |
myproject: 002 | library: isCreatedAt | "15-5-2013 12:11" | myproject: 002 |
myproject: NominalLoadWeightDeckCraneB710 | library: hasMagnitude | "400" | myproject: 003 |
myproject: 003 | library: isCreatedBy | "John Doe" | myproject: 003 |
myproject: 003 | library: isCreatedAt | "15-5-2013 12:15" | myproject: 003 |
Важной частью методологии является идентификация элементов справочных данных в контексте применения ИСО 15926, а также в области системного проектирования для расширения управляемого набора существующих библиотек справочных данных (RDL). Чтобы построить подобный набор элементов справочных данных, в настоящем стандарте используются следующие элементы из пространства RDF-имен:
- rdf:type;
- rdf:Property;
- rdfs:Class;
- rdfs:subClassOf;
- rdfs:subPropertyOf.
В настоящем стандарте взаимосвязь "is a specialization" (является специализацией) идентична "rdfs:subClassOf", а взаимосвязь "is an instance of" (является экземпляром) идентична "rdf:type".
Для того, чтобы можно было использовать ИСО/ТС 15926-4 совместно с настоящим стандартом в контексте RDF-конфигурации, существует класс "thing", определяемый как rdf:type или rdfs:Class. В упрощенном виде, корневой элемент "thing" ИСО 15926-2 можно рассматривать как корневой класс для всех объектных классов настоящего стандарта (см. рисунок 8). Корневые классы настоящего стандарта адаптированы на рисунке 8 подклассам с целью описания информационных моделей в соответствии с разделом 6.
путем мэппинга rdfs:Class в part2:thing
Рисунок 8 демонстрирует, что корневой элемент "thing" является обобщением исходного набора базовых классов, приведенных в настоящем стандарте и взятых из сущностей ИСО 15926-2, которые в свою очередь относятся к классам Библиотеки справочных данных ИСО/ТС 15926-4.
Методология, описанная в настоящем стандарте, позволяет определить закрытые классы (внутренние члены класса) как специализацию классов в Библиотеке справочных данных. Далее эти специализации составляют часть модели продукта, проекта и/или процесса и ссылаются на класс в Библиотеке справочных данных посредством UID конкретного класса в соответствии с ИСО/ТС 15926-4.
Пример - На рисунке 9 показан пример того, как отдельный элемент (экземпляр класса RDL) соотносится с rdfs:Resource.
"myproject:MyCar", являющийся экземпляром транспортного
средства, как это определено в библиотеке
ИСО/ТС 15926-4, соотносится с rdfs:Resource
Для расширения RDF-среды в рамках настоящего стандарта инкорпорируется библиотека справочных данных взаимосвязей. Корневым элементом Библиотеки справочных данных взаимосвязей является элемент "part11:relationship", который определяется как rdf:type элемента rdf:Property. Все взаимосвязи в рамках исходного набора в настоящем стандарте являются элементами rdfs:subPropertyOf корневого элемента "part11:relationship".
взаимосвязей с корневым элементом "part11:relationship"
В настоящем стандарте определены два вида взаимосвязей:
- взаимосвязи в контексте создания утверждений о данных системного проектирования;
- взаимосвязи с целью создания утверждений об утверждениях (метаданные).
Оба вида взаимосвязей определены в исходном наборе взаимосвязей, как это показано в приложении A.
Пример 1 - "Objective A is threatened by risk B" (Достижение цели A находится под угрозой риска B) является утверждением в контексте системного проектирования.
Пример 2 - "Statement A is created by person B" (Утверждение A создано лицом B) является утверждением об утверждении.
Правила использования:
- когда обмениваются утверждениями в рамках цепочки снабжения, то следует использовать только взаимосвязи в предписанном направлении. Обратное имя взаимосвязи должно использоваться только конечным пользователем в сочетании с заменой субъекта и объекта исходя из позиции в утверждении;
- при применении настоящего стандарта каждая взаимосвязь должна уточняться с помощью взаимосвязей доменов и диапазонов, чтобы выбрать правильный набор объектов для подключения на уровне класса или экземпляра (см. пример на рисунке 21).
Применение данной функциональности в рамках среды управления конфигурацией повысит семантическое качество утверждений и, следовательно, качество информационного моделирования.
Примечание - Для корневого элемента "part11:relationship" действует то же самое определение, что и для сущности "relationship" ИСО 15926-2.
В данном разделе методология семантического моделирования описана на логическом уровне, состоящем из набора правил, позволяющих пользователям последовательным образом объединять RDF-триплеты, именованные RDF-графы, набор взаимосвязей и классы RDL для построения моделей продукции и/или процесса. В рамках данной методологии существует три типа элементов "building constructs" (используемые структурные компоненты), все они представлены конкретным видом именованного графа:
- "individual graph" (отдельный граф), при котором любой новый класс объекта или класс экземпляра будет представлен в модели продукта, проекта и/или процесса, "individual graph" (отдельный граф) является только "местом для заполнения" (placeholder) для конкретного класса или экземпляра и, на данном этапе, не добавляет семантики классу или экземпляру, а только определяет метку (обозначение) для URI класса объекта или экземпляра класса;
- "relationship class Graph" (граф класса взаимосвязи). Этот вид графа представляет, классифицирует и предписывает взаимосвязь в виде имени и разрешенного домена и диапазона;
- "statement graph" (граф утверждения), который используется для создания конкретного утверждения о другом утверждении или любом объекте, представленном в "individual graph".
Рассмотренные три типа именованных графов дают возможность интеграции библиотеки и экземпляров классов в одну среду именованного RDF-графа. Специализации классов Библиотеки справочных данных на основе ИСО/ТС 15926-4 могут быть также интегрированы в модель продукта, проекта и/ или процесса.
Правила объединения:
- каждое утверждение имеет свой собственный тип именованного RDF-графа, как это определено в настоящем стандарте путем назначения одного из трех типов именованных графов;
- используемые взаимосвязи происходят из исходного набора взаимосвязей, представленного в разделе 7. Исходный набор взят из справочных моделей ИСО/МЭК 15288, указанных в разделе 6.2;
- для каждой взаимосвязи в рамках исходного набора определено, какой наивысший класс в иерархии определен для субъекта и объекта взаимосвязи. Таким образом, каждому подклассу соответствующего высшего класса разрешено быть субъектом (доменом) относительно объекта (диапазона) взаимосвязи;
- если кто-то желает ограничить использование взаимосвязи в виде домена или диапазона, может быть произведена специализация конкретной взаимосвязи с использованием графа класса взаимосвязи;
- каждый именованный граф включает, как минимум, метаданные о своем создателе и дате/времени своего создания.
В настоящем стандарте приведены два сценария, каким образом управлять изменениями информации, представленной именованными графами:
- разрешена модификация именованных графов: модифицированный именованный граф получает дополнительные метаданные, дата/время модификации в дополнение к дате/времени создания и информации о создателе;
- никакие модификации для графов не разрешены, чтобы обеспечить полную прослеживаемость истории (т.е. ничто не будет когда-либо удалено). Конкретный граф, подлежащий модификации, будет заменен новым с взаимосвязью "replaces" (взамен) к URI замещенного графа. Взаимосвязь "replaces" может содержаться в том же именованном графе, что и новый именованный граф, который замещает старый именованный граф, или может быть "is replaced by" (заменен на) взаимосвязь в старом именованном графе, либо может содержаться в отдельном именованном графе посредством взаимосвязи "is replaced by" (заменен на). В зависимости от контекста применения можно выбрать, какой из этих трех механизмов использовать.
Примечание 1 - Для понятий создатель, создан, изменен используются термины Дублинского ядра (dc:creator, dc:created и dc:modified).
Примечание 2 - Для понятия "replace relationship" используется термин Дублинского ядра dc:isReplacedBy или dc:replaces.
На рисунке 11 представлены три типа именованных графов, указанных в 5.1. С этой целью для рассмотренных трех типов именованных графов из сообщества W3C заимствован в виде корневого класса RDF-подкласс rdfg:Graph.
графов, определенных в настоящем стандарте
На рисунке 12 представлен способ специализации взаимосвязей из исходного набора, пригодный для использования в конкретном контексте проекта или продукта.
из исходного набора взаимосвязей
С целью позиционирования именованного графа в его контексте необходимо добавить метаданные. Для этого, в рамках данной методологии, используются нижеуказанные термины из Дублинского ядра (/template/go.php?url=https://dublincore.org):
- dc:creator;
- dc:created;
- dc:modified;
- dc:source;
- dc:language;
- dc:description;
- dc:provenance;
- dc:replaces, dc:isReplacedBy.
Для описания метаданных именованного графа используются следующие предикаты из пространства имен RDFS:
- rdfs:label;
- rdfs:domain;
- rdfs:range.
С целью описания метаданных, определяющих контекст именованного графа, не охватываемого Дублинским ядром и/или RDF(S) в исходном наборе взаимосвязей определены следующие дополнительные взаимосвязи:
- part11:hasReverseLabel;
- part11:domainIsRestrictedByClass;
- part11:rangeIsRestrictedByClass;
- part11:hasModality;
- part11:hasIntention;
- part11:hasCertainty;
- part11:hasCardinality;
- part11:hasMinCardinality;
- part11:hasMaxCardinality;
- part11:hasAsBeginOfLife;
- part11:hasAsEndOfLife;
- part11:isModifiedBy;
- part11:concernsStage.
5.4.1 Представление основных типов именованных графов, используемых в настоящем стандарте
В данном разделе три структурных компонента методологии именованных графов определены посредством конкретного именованного графа для каждого структурного компонента (см. 5.1 и рисунок 13), как это показано на рисунке 13, рисунке 14 и рисунке 15 соответственно. Графики на рисунках 13, 14 и 15 сосредоточены вокруг URI именованного графа.
представляющий класс "part11:IndividualGraph"
класс "RelationshipClassGraph"
представляющий класс "StatementGraph"
Для именованного графа взаимосвязи (предикаты) представлены между этим именованным графом и различными видами объектов типа создатель, дата и время создания, язык, представляющими собой метаданные и классификацию именованных графов.
Корневой элемент part11:relationship, являясь корневой взаимосвязью настоящего стандарта (см. рисунок 10), определяется посредством экземпляра part11:RelationshipClassGraph. Каждая взаимосвязь, определенная в Библиотеке справочных данных взаимосвязей, будет являться элементом rdfs:subPropertyOf корневого элемента part11:relationship.
На рисунке 16 данная корневая взаимосвязь представлена посредством именованного графа с URI part11:relationship.
корневой класс "part11:relationship"
5.4.2 Представление конкретных элементов проекта
Набор именованных графов может использоваться для определения конкретных элементов проекта. Далее представлен пример, в котором легковой автомобиль (MyCar) состоит из двигателя (MyEngine) и символьного операнда, имеющего свойство "Power of the car". Это свойство имеет свои единицы измерения; присвоенное значение свойства будет заменено на новое значение.
MyCar, MyEngine и "Power of the car" являются экземплярами классов, содержащихся в RDL.
Во-первых, на рисунке 17 место для заполнения значения для MyCar представлено посредством экземпляра отдельного графа с URI myproject:MyCar. В именованном графе метка (обозначение) для экземпляра класса "MyCar" присвоена данному URI. Позднее (рисунок 28) экземпляр класса MyCar будет классифицирован как машина в соответствии с ИСО 15926-4.
место для заполнения для "MyCar"
На рисунке 18 представлено место для заполнения для экземпляра класса "MyEngine" и позднее, на рисунке 29, он будет классифицирован как "engine" (двигатель) в соответствии с ИСО/ТС 15926-4.
место для заполнения для "MyEngine"
На рисунке 19 представлено место для заполнения для свойства "Power of my car" (мощность моей машины) с URI myproject:PowerOfMyCar и позднее, на рисунке 33, оно будет классифицировано как "nominal power" (номинальная мощность) в соответствии с ИСО 15926-4.
место для заполнения для "PowerOfMyCar"
5.4.3 Представление конкретных взаимосвязей проекта
Первым шагом основная версия взаимосвязи "consists of" (состоит из) вводится в проект (в рамках рассматриваемого примера) посредством элемента part11:RelationshipclassGraph с URI part11:consistsOf (см. рисунок 20) и адресным указателем "consists of" (состоит из), и определяется как rdfs:subPropertyOf элемента part11:relationship в соответствии с рисунком 16.
взаимосвязь part11:consistsOf как rdfs:subPropertyOf
корневого элемента part11:relationship
ИС NORMPROD: примечание. В официальном тексте документа, видимо, допущена опечатка: имеется в виду рисунок 21, а не рисунок 20. |
Вторым шагом на рисунке 20 введенная основная версия взаимосвязи "consists of" специализируется, в рамках данного примера, для взаимосвязи в пространстве имен "myproject" с доменом и диапазоном, оба из которых объявляются как экземпляры RDL класса "physical object" (физический объект). URI присвоено значение myproject:myConsistOf и метка (обозначение) "consist of Physical Object".
в рамках пространства имен "myproject" (см. рисунок 20)
взаимосвязь с меткой (обозначением) "consistsOf"
для взаимосвязи с меткой (обозначением)
"consistsOfPhysicalObject"
На рисунке 22 взаимосвязь с меткой (обозначением) "has modality" (имеет модальность) из исходного набора представлена URI part11:hasModality и меткой (обозначением) "has modality" как rdfs:subPropertyOf элемента part11:relationship (см. рисунок 16).
взаимосвязь части 11 с меткой (обозначением) "has modality"
На рисунках 23, 24, 25, 26 и 27 нижеуказанные взаимосвязи представлены в пространстве имен "part11" аналогичным образом, что и на рисунке 22 "part11:hasModality": part11:isQuantifiedIn, part11:hasMagnitude, part11:hasCertainty, part11:hasIntention и part11: hasProperty.
взаимосвязь part11 с меткой (обозначением)
"is quantified in"
взаимосвязь part11 с меткой (обозначением) "has magnitude"
взаимосвязь part11 с меткой (обозначением) "has certainty"
взаимосвязь part11 с меткой (обозначением) "has intention"
взаимосвязь part11 с меткой (обозначением) "has property"
5.4.4 Представление конкретных утверждений проекта
В предыдущих разделах представлены места заполнения и определены необходимые взаимосвязи. В настоящем разделе они используются для создания утверждений о конфигурации продукта и утверждений об утверждениях. В рассматриваемом примере метки (обозначения) мест заполнения размещены в отдельных утверждениях, поддерживающих их контролируемое изменение. Эти метки (обозначения) могут также быть частью именованного графа, который определяет место заполнения.
На рисунке 28 URI myproject:MyCar с меткой (обозначением) "MyCar" определен как экземпляр класса "part4:MotorVehicle" ИСО/ТС 15926-4.
на то, что "MyCar" является экземпляром RDL
класса "part4:MotorVehicle"
На рисунке 29 утверждение устанавливает, что URI myproject:MyEngine с меткой (обозначением) "My Engine" является экземпляром класса "part4:Engine" ИСО/ТС 15926-4.
на то, что "My Engine" является экземпляром RDL
класса "part4:Engine"
На рисунке 30 утверждение создано с помощью URI myproject:MyCarConsistOfMyEngine и указывает на то, что myproject:MyCar состоит из myproject:MyEngine на основе предиката с URI myproject:myConsistOf.
на то, что "MyCarConsistsOfMyEngine" (моя машина
состоит из моего двигателя)
На рисунке 31 утверждение указывает на то, что myproject:MyCar имеет свойство myproject:PowerOfMyCare, используя взаимосвязь part11:hasProperty.
на то, что "MyCar" имеет свойство "PowerOfMyCar"
На рисунке 32 приведено утверждение, которое указывает на то, что для myproject:MyCar требуется свойство (значение модальности, равное "shall have") myproject:PowerOfMyCar.
на то, что утверждению MyCar следовало бы иметь
("shall have") свойство PowerOfMyCar посредством
взаимосвязи part11:hasModality
На рисунке 33 утверждение указывает на то, что myproject:PowerOfMyCar является экземпляром класса номинальной мощности ИСО/ТС 15926-4.
на то, что утверждение со свойством "PowerOfMyCar"
классифицируется как номинальная мощность
в соответствии с RDL классом "NominalPower"
На рисунке 34 утверждение указывает на то, что myproject:PowerOfMyCar (мощность моей машины) должна измеряться с помощью класса "kW" ИСО/ТС 15926-4.
на то, что утверждение со свойством myproject:PowerOfMyCar
выражено в кВт в соответствии с RDL классом "kW"
На рисунке 35 утверждение указывает на то, что свойство myproject:PowerOfMyCar имеет значение, равное 240.
на то, что утверждение со свойством PowerOfMyCar
имеет значение, равное 240
На рисунке 36 утверждение указывает на то, что значение свойства myproject:PowerOfMyCar (равное "240") является предположением.
на то, что утверждение о значении свойства
myproject:PowerOfMyCar, равном "240",
является предположением
На рисунке 37 утверждение указывает на то, что значение свойства myproject:PowerOfMyCar является оценочной величиной.
на то, что утверждение со значением свойства
PowerOfMyCar является оценочной величиной
На рисунке 38 утверждение указывает на то, что значение свойства myproject:PowerOfMyCar изменено на "250". Посредством dc:provenance это изменение обосновано. Данный именованный граф заменяет именованный граф на рисунке 35.
на то, что утверждение со значением свойства PowerOfMyCar,
значение которого изменено на "250", обосновано
На рисунке 39 утверждение указывает на то, что значение, равное "250", свойства myproject:PowerOfMyCar одобрено.
на то, что утверждение со значением свойства
PowerOfMyCar одобрено
На рисунке 40 утверждение указывает на то, что значение, равное "250", свойства myproject:PowerOfMyCar является расчетным.
на то, что утверждение со значением свойства
PowerOfMyCar содержит расчетное значение
В данном разделе приведен пример того, как настоящий стандарт можно использовать для определения моделей продукта на уровне классов. Как это показано в 5.3, подход идентичен подходу, используемому при создании моделей проекта или экземпляра. Во-первых, введены указатели на места заполнения для классов части продукции. Во-вторых, определены требуемые взаимосвязи, а в-третьих, созданы утверждения, включая утверждения об утверждениях.
Пример описывает, как тип насоса может быть определен бригадой экспертов с помощью настоящего стандарта в сочетании с Библиотекой справочных данных (RDL). Насос этого типа должен состоять как минимум из 2 и максимум из 4 крыльчаток насоса и иметь мощностные характеристики, соответствующие данному типу насоса.
В данном примере повторно используются взаимосвязи из взаимосвязей пространства имен part11, как это определено в 5.4.
5.5.1 Представление конкретных элементов продукта
На рисунке 41 для продукта "Pump type A" (насос типа A) вводится место заполнения посредством экземпляра конкретного графа.
заполнения для "PumpType" (тип насоса)
На рисунке 42 место заполнения для детали продукта "Impeller type B" (крыльчатка типа B) представлено посредством экземпляра конкретного графа.
заполнения для "ImpellerType" (тип крыльчатки)
На рисунке 43 место заполнения для свойства "Nominal power of pump type A" (номинальная мощность насоса типа A) представлено посредством экземпляра конкретного графа.
заполнения для "PumpTypePower" (мощность насоса типа)
5.5.2 Представление конкретных взаимосвязей проекта
На рисунке 44 взаимосвязь "part11:consistsOf" (см. рисунок 20) специализирована для взаимосвязи с доменом, ограниченным подклассами "physical object" (физический объект) ИСО/ТС 15926-4 и диапазоном, ограниченным подклассами "physical object" (физический объект) ИСО/ТС 15926-4.
взаимосвязь part11:consistsOf для взаимосвязи
myproduct:ConsistsOfByClassOfPhysicalObject
Поскольку элементы rdf:domain и rdf:range указывают на экземпляры классов в этом именованном графе, то взаимосвязи part11:domainIsRestrictedByClass и part11:rangeIsRestrictedByClass используются для уточнения домена и диапазона, конкретно используемых для указания (под)классов.
На рисунке 45 взаимосвязь "hasMinCardinality" из исходного набора взаимосвязей введена в модель продукта.
взаимосвязь MinCardinality из исходного набора взаимосвязей
На рисунке 46 взаимосвязь "hasMaxCardinality" из исходного набора взаимосвязей введена в модель продукта.
hasMaxCardinality из исходного набора взаимосвязей
5.5.3 Представление конкретных утверждений о продукте
На рисунке 47 элемент myproduct:PumpType (с меткой (обозначением) "Pump type A") определяется как подкласс класса "pump" в соответствии с ИСО/ТС 15926-4.
myproduct:PumpType как подкласс класса "pump"
в соответствии с ИСО/ТС 15926-4
На рисунке 48 myproduct:ImpellerType (с меткой (обозначением) "Impeller type B") определяется как подкласс класса "Impeller" в соответствии с ИСО/ТС 15926-4.
myproduct:ImpellerType как подкласс класса "Impeller"
в соответствии с ИСО/ТС 15926-4
На рисунке 49 приведено утверждение, что класс myproduct:pumpType (с меткой (обозначением) "Pump type A") состоит из класса myProduct:impellerType (с меткой (обозначением) "Impeller type B").
на то, что класс myproduct:PumpType обычно состоит
из класса myproduct:ImpellerType
На рисунке 50 приведено утверждение, что утверждение myProduct:ProductTypeConsistsOfImpellerType имеет минимальное кардинальное число, равное двум. Таким образом, экземпляр класса myproduct:pumpType (с меткой (обозначением) "Pump type A") состоит, как минимум, из двух экземпляров myProduct:impellerType (с меткой (обозначением) "Impeller type B").
на то, что экземпляр класса myproduct:PumpType состоит,
как минимум, из двух экземпляров myproduct:ImpellerType"2"
На рисунке 51 приведено утверждение, что утверждение myproduct:ProductTypeConsistsOfImpellerType имеет максимальное кардинальное число, равное четырем. Таким образом, экземпляр класса myproduct:PumpType (с меткой (обозначением) "Pump type A") состоит, как максимум, из четырех экземпляров myproduct:ImpellerType (с меткой (обозначением) "Impeller type B").
на то, что экземпляр класса myproduct:PumpType
состоит, как максимум, из четырех экземпляров
myproduct:ImpellerType"4"
На рисунке 52 утверждение указывает на то, что myproduct:PumpTypePower (с меткой (обозначением) "Nominal power of pump type A") является экземпляром класса номинальной мощности ИСО/ТС 15926-4.
myproduct:PumpTypePower как экземпляр класса "NominalPower"
в соответствии с определением данного класса
в ИСО/ТС 15926-4
На рисунке 53 приведено утверждение, что myproduct:PumpTypePower измеряется в кВт в соответствии с ИСО/ТС 15926-4.
на то, что myproduct:PumpTypePower измеряется в кВт
в соответствии с его определением в ИСО/ТС 15926-4
На рисунке 54 приведено утверждение, что измерение myproduct:PumpTypePower, которое приводится в кВт, является произвольным со значением модальности "can be" (может быть), как это определено в пространстве имен "library".
на то, что утверждение myproduct:PumpTypePower2
имеет значение модальности "can be"
На рисунке 55 приведено утверждение, что myproduct:PumpTypePower измеряется в единицах измерения лошадиная сила (hp) в соответствии с ИСО/ТС 15926-4.
на то, что myproduct:PumpTypePower измеряется в лошадиных
силах в соответствии с его определением в ИСО/ТС 15926-4
На рисунке 56 приведено утверждение, что измерение в лошадиных силах myproduct:PumpType Power является произвольным со значением модальности "can be" (может быть), как это определено в пространстве имен "library" по отношению к именованному графу "myproduct:PumpTypePower4".
на то, что утверждение myproduct:PumpTypePower4
имеет значение модальности "can be"
Технические данные в контексте настоящего стандарта охватывают не только входы и/или выходы технологических процессов, но также и сами технологические процессы. Таким образом, настоящий стандарт делает возможным интеграцию и обмен техническими данными совместно с данными, относящимися к системному проектированию. Другие части комплекса международных стандартов ИСО 15926 недостаточно полно охватывают аспекты системного проектирования в части информационного обмена в области жизненного цикла перерабатывающих предприятий.
Пример - Конкретные требования, методы испытаний и техническое обслуживание являются примерами данных системного проектирования.
С целью получения полного набора взаимосвязей, применимых в контексте системного проектирования, в качестве первоисточника был использован ИСО/МЭК 15288.
Для реализации системы в ИСО/МЭК 15288 определены 25 процессов, начиная от утверждения целей системы и набора высокоуровневых требований (заинтересованные стороны) и завершая ее эксплуатацией и обслуживанием.
Для подготовки исходного набора взаимосвязей, приведенных в настоящем стандарте, с учетом общих описаний процесса жизненного цикла системы, приведенных в ИСО/МЭК 15288 составлен набор информационных моделей. Набор информационных моделей функционирует в качестве справочной онтологии системного проектирования. Поэтому информационные модели могут быть также использованы в качестве справочных моделей при системном проектировании.
В качестве примера, возможными выходными данными работы контрактора могут быть согласованная клиентом и контрактором информационная структура, отраженная в Справочнике по доставке информации (IDM). Согласованная информационная структура может быть подмножеством представленных в данном разделе справочных моделей (со временем она может быть также модифицирована).
Настоящий стандарт позволяет реализовать в явном виде информационные справочные модели, используемые в системном проектировании, определяя все детали, которые предусмотрены и имеют отношение к данным моделям. На этой основе любой желающий может разработать системы управления конфигурацией и информацией и посредством этого обмениваться информацией системного проектирования в явном и однозначном виде.
Данные модели также позволяют изготовителям и/или поставщикам продукции создавать для их продукции так называемые "модели знаний о продукции" таким образом, что информация о продукте может быть легко интегрирована в среду системного проектирования на основе тех же самых информационных моделей.
Каждый элемент в рамках утверждения (элемент с ролью 1, взаимосвязь и элемент с ролью 2) должен обладать прослеживаемостью для возможности определения этого элемента. По этой причине настоящий стандарт следует использовать совместно с Библиотекой справочных данных ИСО 15926 (RDL, ИСО/ТС 15926-4) или сопоставимой ей. Прослеживаемость для определения может быть достигнута, если каждый раз, когда новый элемент (сущность) вводится в утверждение, проводится классификационное сопоставление между новым введенным элементом и соответствующим классом RDL.
На рисунке 57 представлена структура RDL на основе элементов (сущностей), взятых из ИСО 15926-2, которая может использоваться в качестве структуры корневых классов RDL для системного проектирования. Приведенные на рисунке 57 классы представляют собой центральные корневые классы, используемые в рассматриваемых информационных моделях.
терминов в контексте системного проектирования,
используемых в информационных моделях в рамках
настоящего стандарта
Для каждого отношения в рамках исходного набора взаимосвязей на основе информационных моделей определено, какие объекты разрешены на левой, а какие на правой стороне взаимосвязи.
В настоящем стандарте модели справочной информации установлены на основании принципов, изложенных в 4.1. Область системного проектирования, в соответствии с настоящим стандартом, включает следующие информационные модели:
- модель технологической и физической частей системы (рисунок 58);
- модель структурной декомпозиции физической части системы (рисунок 59);
- модель описания физических объектов на основе свойств и статуса (рисунок 60);
- модель взаимодействия между элементами системы, а также между элементами системы, средой и заинтересованными сторонами (рисунок 61);
- модель режимов отказа и анализа воздействий на систему (рисунок 62);
- модель анализа технических требований системы (рисунок 63);
- модель верификации технических требований системы (рисунок 64);
- информационная модель управления рисками (рисунок 65);
- модель процесса управления изменениями контракта (рисунок 66);
- (структурная) модель распределения работ в системе (рисунок 67);
- модель информационного потока между участниками (рисунок 68);
- модель проектных организаций (рисунок 69);
- информационная модель оценки (рисунок 70);
- информационная модель допущений/предположений (рисунок 71);
- модель подключения и взаимодействия с физическими объектами (рисунок 72);
- модель документов и версий документов (рисунок 73).
На основе представленных в настоящем стандарте информационных моделей, которые следует рассматривать как справочные модели, получен исходный набор взаимосвязей (см. приложение A; исходный набор взаимосвязей).
Каждую взаимосвязь в рамках исходного набора можно найти в одной из приведенных информационных моделей и каждое утверждение содержит контекст и метод использования рассматриваемой взаимосвязи. Каждая взаимосвязь с левыми и правыми объектами представляет собой утверждение в контексте системного проектирования.
На рисунке 58 представлены сущности разрабатываемой системы. Разработка системы начинается с утверждения участниками ее целей и задач. Существует, как минимум, одна задача для целевой системы и одна задача для системы (на уровне предприятия), которая реализует целевую систему. После определения целей и задач для их достижения "начинают выполняться" процессы жизненного цикла системы.
технологическую и физическую часть системы путем
определения соответствующих сущностей
и взаимосвязей между ними
Пример - Примерами процессов жизненного цикла системы являются процессы эксплуатации и определения требований, процесс проектирования архитектуры и т.д.
Следующим шагом является определение сервисов (служб), которые следует реализовать для того, чтобы процессы могли выполняться для достижения поставленных целей и задач. С одной стороны сервисы обеспечивают условия процесса, а с другой стороны они сами нуждаются в условиях процесса (фактически в начальных условиях).
Сервисы могут быть реализованы посредством одной или более технических функций функционального физического объекта и/или человеческой деятельности. Функциональные физические объекты имеют одну или более технических функций, т.е. функциональные возможности выполнить сервисы (или их часть). Как сервисы, так и техническая функция являются подклассами деятельности.
При разделении сервиса на технические функции и человеческую деятельность решение принимается на уровне автоматизации сервиса, что разделяет ответственность оператора/персонала сопровождения и системного архитектора/разработчика системы для достижения целей/задач.
Задачи, процессы, условия процесса и сервисы формируются на основе спецификаций требований заинтересованных сторон (техническое задание). Спецификации требований к системе берутся из отдельных требований заинтересованных сторон. Система состоит из функциональных физических объектов, которые выполняют технические функции.
На рисунке 59 представлена информационная модель, представляющая структурную декомпозицию системы. В рамках данной модели рассматриваются четыре уровня реализации физического объекта:
- функциональный физический объект;
- специфицированный физический объект;
- модель производителя;
- материализованный физический объект.
структурную декомпозицию физической части системы
Функциональный физический объект может быть определен на нескольких абстрактных уровнях, от подсистемы (например, системы мониторинга) до уровня оборудования (например, насоса) или материализованного уровня. На уровне подсистемы функциональный физический объект находится в структурной декомпозиции, учитывая принципы разработки, что ведет к появлению набора новых функциональных физических объектов. На уровне оборудования функциональный физический объект находится в структурной декомпозиции и использует выбранную модель производителя. Фактически модель производителя является выбранным решением для функционального физического объекта, которое будет действовать в течение временной части функционального физического объекта и будет иметь уникальный экземпляр в течение временной части жизненного цикла системы. Используя взаимосвязи "begin of life" (начало жизни) и "end of life" (конец жизни), можно определить существование материализованного физического объекта во времени для более чем одного функционального физического объекта.
Модель производителя соответствует установленным принципам разработки, основана на конкретной технологии и соответствует конкретному способу производства и топологии.
При задании свойств различным абстрактным уровням физического объекта можно использовать взаимосвязь "concerns stage" (касается этапа) для задания конкретного свойства конкретному этапу, поскольку в целом существует взаимосвязь между уровнем абстракции физического объекта и этапом его жизненного цикла.
Примечание - В так называемой "hamburger model" (модели гамбургера) (Функциональная Единица - модель Технического Решения) функциональный физический объект и специфицированный физический объект объединены в функциональную единицу. Модель гамбургера описана в Общей эталонной модели программных систем в сфере строительства и архитектуры (General AEC reference model; GARM), являющейся интеграционной моделью для применения в сферах строительства и архитектуры, которая была определена в ранние годы развития стандарта обмена данными STEP.
На рисунке 60 представлена информационная модель, относящаяся к свойствам элемента "possible individual" (возможный индивид; возможный индивидуальный объект, см. ИСО 15926-2) системы со специальным подходом для уникальных экземпляров классов (целой жизни индивида в конкретном состоянии). Сколько элемент системы (например, это может быть физический объект, деятельность или событие) существует на уровне класса или уровне спецификации, столько же свойство сопровождается диапазоном свойств, определяемыми верхней и нижней границами и единицами измерения, в которых это свойство выражено. Как только элемент системы реализован и будет находиться в конкретном состоянии, реальное свойство будет иметь конкретную величину и будет выражено в конкретных единицах измерения.
упрощенное использование свойств и статуса (на основе
модели данных, определенной в ИСО 15926-2)
Свойство не всегда выражается единицами измерения, оно может также выражаться строковой величиной, будучи индивидуальным объектом. В этом случае свойство может быть квалифицировано конкретным именем, где посредством нумерации несколько строковых величин могут определяться последовательным образом, каждый с заданным именем в виде возможного значения для конкретного свойства, например квалификацию свойства можно назвать IP 44, IP 55 и IP 66 как возможные IP классы в контексте свойства "Protection Rating" (класс защиты).
Аналогичным образом могут быть определены возможные состояния элемента системы путем определения класса возможных значений статуса. На уровне экземпляра элемента системы, состояние индивидуального объекта, а именно конкретный статус может быть идентифицирован с помощью имени (например, "red" (красный) или "green" (зеленый) в случае использования цвета).
Функциональные физические объекты взаимодействуют со своей средой посредством интерфейса. Интерфейс функционального физического объекта состоит из портов, как это показано на рисунке 61. Существует 4 основных вида портов: материальный порт, энергетический порт, информационный порт и конструкционный (3D) порт. Взаимодействия могут происходить между функциональными физическими объектами, а также между функциональными физическими объектами, средой и/или заинтересованными сторонами.
На основе моделей, представленных на рисунках 59, 60 и 61, производители могут создавать свои собственные модели знаний о продукции, которые могут быть использованы и интегрированы в процесс разработки/проектирования систем.
После реализации функционального физического объекта материализованным физическим объектом, порты, определенные на уровне функционального физического объекта, будут также материализованы и станут конкретными физическими взаимосвязями.
взаимодействия между внутренними элементами системы
и взаимодействия между элементами системы, средой
и/или заинтересованными сторонами
На рисунке 62 представлена информационная модель, относящаяся к режимам отказов системы. Модель основана на определении возможных неисправностей технических функций, выполняемых функциональным физическим объектом. Режим отказа является причиной для определения одного или более типов технического обслуживания, процессов тестирования задачи и/или мер безопасности, которые определены процедурой, содержащейся в документе.
отказов и анализ воздействий системы путем определения
соответствующих элементов и взаимосвязей
между этими элементами
Режимы отказов, выявляемые сигналом системы управления, обеспечивают приведение в готовность средств технического обслуживания и/или тревожный сигнал для оператора, которые должны инициировать соответствующую деятельность.
Для выполнения работ по техническому обслуживанию в соответствии с моделью производителя необходимо использовать запасные части, которые сами по себе также могут являться моделью производителя.
При проведении анализа требований (см. рисунок 63), спецификации требований классифицируются по степени серьезности, видам инженерных дисциплин, типам требований и по тому, какие характеристики системы рассматриваются в спецификациях требований. Спецификации требований предназначены для экспертной группы, в чьи полномочия входит работа с клиентами.
требований системы путем определения соответствующих
сущностей и взаимосвязей между ними
В целом же спецификация требований (технические требования) состоит из проектных ограничений, функциональных и эксплуатационных требований.
Спецификации требований определяются элементом "text fragment" (текстовый фрагмент), который имеет статус в контексте его жизненного цикла, версию и источник, может являться контрактом или другим документом.
Базовая линия может быть обозначена одним или более элементами версий, которые используются для идентификации версии текстовых фрагментов.
Сами по себе технические требования имеют статус, который может быть, например назначен элементу системы, ожидать назначения, быть отложенным (не требуется выполнения), если требование больше не является существенным, учтенным "taking count of" или выполненным.
Соответствие установленным техническим требованиям должно быть продемонстрировано клиенту контрактором (лицом, заключившим контракт), чтобы доказать, что продукт или система будет исполнена должным образом. Доказательство того, что технические требования выполнены, называется верификацией. Каждое техническое требование (см. рисунок 64) имеет одно или более связанных с ним верификационных действий, в зависимости от того, для какого этапа жизненного цикла системы требуется верификация. Например, одно требование может быть верифицировано на стадии проектирования и строительства, а для другого требования необходима верификация на этапе обслуживания системы.
Каждое верификационное действие относится к конкретному проверяемому изделию/продукту. Это может быть отдельное изделие, конкретная система, объект или деятельность. Также верификации может подлежать процесс, который является классом.
верификации технических требований путем определения
соответствующих элементов и взаимосвязей
Это означает, что если, например конкретное техническое требование, относящееся к конкретной системе, проверяется на трех этапах жизненного цикла этой конкретной системы, то существуют три верификационных действия, каждое из которых может иметь свой метод (например, пересмотр, расчет, имитация (моделирование), инспекция), область применения (например, полномасштабная, выборочная, типовая) и процедуру (протокол испытаний).
Для каждого верификационного действия может понадобиться уточнение критерия приемки из-за неопределенного характера технического требования. Фактически, указанный критерий приемки является расширением технического требования и становится его частью.
Верификационное действие может зависеть от статуса соответствия, причины отклонения от контракта, например когда техническое требование демонстрирует себя как невыполнимое.
Верификация всегда имеет статус (например, активная, оконченная) и выполняется лицом в зависимости от статуса должностных обязанностей (например, руководителем конструкторского отдела) и/или конкретно назначенным оператором.
Управление рисками требует контроля информации, которая характеризует риск, а также информации о возможности снижения конкретного риска.
Риск является угрозой для выполнения поставленных целей и задач, связанных с целями/задачами систем и/или процессов (рисунок 65). Риск имеет конкретные причины и следствия, и за него несет ответственность конкретное лицо или организация. Следствия ведут к негативным воздействиям в части стоимости, времени, качества, безопасности, экологии и/или доступности системы. Оценивая эти последствия и умножая их математическую сумму на вероятность, можно получить категорию приоритета уровня риска, которую далее можно использовать для приоритизации набора рисков.
информацию о процессе управления рисками путем определения
соответствующих элементов и взаимосвязей
Деятельность по управлению рисками осуществляется некоторым лицом в организации (подкласс "party") и сводится к одной или более минимизирующих риск мер в виде одного или более технических требований. С учетом выполнения этих мер и технических требований, тем не менее, существует остаточный риск с новой вероятностью и набором последствий, приводящий к появлению новой категории приоритета уровня риска, но который должен быть существенно ниже основного риска без каких-либо мер или требований.
На рисунке 66 представлен процесс управления изменениями контракта. Центральной сущностью является контрактная поставка (поставляемые по контракту продукты/изделия), которая заявлена заказчиком поставки (например, клиентом) в контракте с контрактором. Контракт заключается между заказчиком и контрактором, где иногда участвует третья сторона (заинтересованная сторона, предпочтительный поставщик и т.п.).
управления изменениями контракта системы путем определения
соответствующих элементов и взаимосвязей
Контрактная поставка должна отвечать одному или более техническому требованию и состоять из поставляемых позиций по пакету (комплексу) работ (см. рисунок 67). Полный набор поставляемых позиций по пакету работ должен соответствовать набору поставляемых по контракту продуктов/изделий.
структурную модель распределения работ в системе путем
определения соответствующих сущностей и взаимосвязей
Для того, чтобы можно было разбить работу на этапы, необходимо определить несколько контрольных точек (меток), в рамках которых часть поставляемых по контракту продуктов/изделий будет принята и некоторые из них будут оплачены (по аналогии с календарным планом и актом выполненных работ по этапу). Эти финансовые контрольные точки (вехи) являются конкретными контрольными точками, как это определено на рисунке 67.
Сложности, связанные с поставкой по контракту изделий, могут стать позднее причиной для внесения изменений в контракт, это должно быть оформлено документально, и их разрешение должно стать завершением пролонгированного контракта.
На рисунке 67 представлена информационная модель распределения работ (структура декомпозиции работ, WBS) системы, охватывающая полный жизненный цикл системы, который, как правило, разделен на несколько этапов. Каждый этап обоснован и подтвержден одной или несколькими целями ("что должно быть достигнуто, когда этап будет завершен"). Цели достигаются путем реализации одного или более пакета (комплекса) работ. Пакет работ состоит из одного или более видов деятельности, создающих конечные результаты, которые вносят свой вклад в подсистему, конкретный функциональный физический объект или материализованный физический объект. Как этапы жизненного цикла, так и пакеты работ могут иметь контрольные точки (вехи), каждая из которых запланирована и описана при планировании деятельности.
Для выполнения входящих в пакет работ различных видов деятельности, создающих конечные результаты, необходимо учитывать результаты, полученные в рамках процесса управления рисками, процесса анализа требований, и процесса проектирования (допущения и спецификации портов для организации возможности интероперабельности). Любая деятельность в конечном счете приводит к новым рискам, требованиям, допущениям и взаимодействиям портов.
Каждая деятельность в рамках пакета работ будет являться экземпляром деятельности в контексте одного из процессов ИСО/МЭК 15288.
Важным элементом в рамках системного проектирования является решение. В рассмотренных моделях решения представлены элементами "design principles" принципы разработки (рисунок 59), "measures" оценки/меры (рисунок 70) и "assumptions" допущения (рисунок 71); все они, по своей сущности, содержат аспекты принятия решения и связаны с деятельностями, включенными в пакет работ и следовательно связаны с контрольными точками, поэтому основные решения могут быть определены только введением конкретных контрольных точек.
Анализ компромиссных решений (технико-экономический анализ), включая окончательный вариант проекта, может быть описан в документах, которые имеют отношение к соответствующим пакетам работ и техническим решениям.
На рисунке 68 представлен формальный коммуникационный поток между участниками проекта. Формальная коммуникация (формальное взаимодействие) здесь определяется как связи между участниками в рамках контракта.
коммуникационный поток между участниками, использующими
сообщения в контексте конкретной деятельности
по выполнению контракта
Контракт состоит из одного или более видов деятельности определенного типа. Деятельность по выполнению контракта может инициироваться и осуществляться как организацией, так и конкретным лицом (используются соответствующие роли). Деятельность по выполнению контракта может находиться в одном из следующих типов состояний: требуемая (requested), обещанная (promised), в процессе реализации (delivered) или принятая (accepted). Типы состояний следуют друг за другом в заранее определенном порядке. Изменение состояния деятельности по выполнению контракта может быть инициировано только посредством формального сообщения/передаваемой информации (formal message), как результата этой деятельности.
Сообщение имеет определенный тип, посылается и принимается сущностью с ролью "party", должно иметь некоторый объект реального мира (thing) в виде субъекта и может быть дополнено документом.
Также сообщение может состоять из набора утверждений, как это определено в рамках настоящего стандарта.
На рисунке 69 представлены сущности организации, участвующие в реализации проекта. В других моделях несколько раз используется термин "участник" ("party"); участник может быть организацией или конкретным лицом (сотрудником).
организационные условия и взаимоотношения
информационную модель конкретной меры (подкласса
деятельности), создаваемую и используемую
в других информационных моделях
информационного объекта), создаваемая и используемая
в других информационных моделях
В рамках данной модели проведено различие между организацией и конкретным лицом (их ролями).
Организация состоит из реальных физических лиц - специалистов (роль - "лицо, сотрудник"; role of a person), рабочих команд и департаментов. Рабочие команды управляются лицами с ролью "сотрудник" и могут состоять из нескольких человек.
Организации и специалисты располагаются в офисе.
В рассматриваемой модели под мерой понимается смягчающая риск мера ("risk mitigating measure"), как это представлено на рисунке 65. Мера характеризуется конкретным потоком операций (workflow), предлагается участником (party), который отвечает за управление рисками и одобряется теми участниками, на которых она оказывает прямое воздействие. Например, мера получает статус "approved" (одобрена), и в дальнейшем назначается конкретный участник, ответственный за ее реализацию.
Для реализации конкретной меры необходимо инициировать выполнение некоторой деятельности из состава пакета работ. Когда мера успешно осуществлена, ее статус изменяется, например на "executed" (выполнена). В этом случае должен появиться документ, который подтверждает осуществление меры.
В рамках потока операций для пояснения хода осуществления меры различными участниками могут быть разработаны утверждения. Мера может быть охарактеризована свойством, которое выражает эффективность.
Сущность "assumption" (допущение) представлена на рисунке 67. Допущение можно использовать для формализации, например проектного решения или интерпретации требования. По аналогии с мерой допущение также характеризуется конкретным потоком операций; допущение предлагается участником (party), осуществляющим деятельность в рамках пакета работ, например проектные работы. Допущение должно одобряться теми участниками, на которых оно оказывает воздействие. В таком случае допущения получают, например, статус "approved" (одобрено), и инициируется деятельность в рамках пакета работ, которая будет иметь допущение в качестве своего результата. Когда допущение успешно проработано, статус деятельности меняется, например, на "executed" (выполнено). В этом случае должен появиться документ, который подтверждает выполнение допущения. В рамках потока операций для пояснения конкретного допущения различными участниками могут быть разработаны утверждения. Допущение может использоваться, например, для прояснения технического требования, как результата деятельности по анализу требований (конкретная деятельность в составе пакета работ), или для описания проектов систем человеческой деятельности.
Несмотря на тот факт, что информационные модели меры и допущения выглядят одинаково, каждая из них представляет собой разные концепции, значения и роли в рамках проектов. По этой причине они не объединяются в рамках одной модели.
На рисунке 72 представлена информация, касающаяся возможности подключения материализованных физических объектов в качестве частей системы. Данная модель, для указания возможных соединений, может включать в себя такие элементы, как магистрали и кабели (тип соединения). Соединение на обоих концах имеет характерные черты (особенности), называемые "end1" (конец1) и "end2" (конец2). Необходимый для установления соединения материал представлен соединением в виде сборки и состоит из материала и физических объектов, как болты и гайки.
возможность подключения физического объекта,
например, посредством магистралей и кабелей
Соединение может иметь одно или несколько свойств, указывающих на пропускную способность, давление, диаметр и т.п. соединения. Соединение может проходить через стенку, разделяющую в пространстве два объекта посредством транзита определенного типа. Соединение может проходить по маршруту, который состоит из одной и более трасс; трасса может состоять из наземной трассы и кабель-канала.
Пространственное расположение может быть также соединено и даже перекрывать друг друга, что может быть точно выражено посредством взаимосвязей "is adjacent to" (смежно расположенный с) в соответствии с "has overlap with" (имеет перекрытие с).
Другой формой соединений является покрытие физического объекта другим физическим объектом или организацией.
На рисунке 73 представлена информация, касающаяся документа и версий документа.
представляющая информацию о документе
Любой элемент типа документа имеет метаданные и взаимосвязи с устойчивыми элементами, такими как автор, источник, а также субъект и тип документа.
В целом документ описывает результаты деятельности в рамках пакета работ, например систему или оборудование (см. рисунок 67).
Элемент главного документа имеет одну или более версий, которые обладают метаданными, такими как дата выпуска, состояние публикации, выпускающий (релизер) и идентификационный код изменения.
Элемент "Baseline" (базовая линия/исходное значение) может быть определен путем идентификации версии, устанавливающей конкретные версии документов.
Для создания, например, моделей продукции, соответствующих настоящему стандарту, следует использовать только те взаимосвязи, которые существуют в рамках исходного набора (см. приложение A) или являются их специализацией.
Исходный набор взаимосвязей определен на основе моделей справочной информации, указанных в разделе 6 (см. рисунки 58 - 73). Взаимосвязи соответствуют сущностям (см. ИСО 15926-2) и основаны на принципах, описанных в приложении D.
Определение, приведенное в приложении A, основано на справочных моделях системного проектирования раздела 6. Индивидуализация (адаптация) взаимосвязей допускается до тех пор, пока она согласуется с определенными доменом и диапазоном (см. приложение A). Индивидуализация взаимосвязей под конкретный проект будет, в этом случае, являться субъектом Справочника по доставке информации (IDM) для данного проекта.
На практике пользователь начинает с объекта, классифицируемого (под)классом RDL, а затем устанавливает взаимосвязи, которые возможны для этого объекта в соответствии с доменом и диапазоном.
ИС NORMPROD: примечание. В официальном тексте документа, видимо, допущена опечатка: колонка 3 в Приложении A отсутствует. |
Если приложение представляет взаимосвязь в обратном направлении, то для представления взаимосвязи пользователю следует использовать обратное имя взаимосвязи, указанное в колонке 3 приложения A.
Аналогичным образом, как и для объектов в библиотеке справочных данных, необходимо поддерживать исходный набор взаимосвязей в таком состоянии, чтобы по запросу промышленности можно было в контролируемом режиме добавлять новые взаимосвязи.
Добавление новых взаимосвязей подразумевает расширение одной из информационных моделей или введение новой информационной модели в настоящий стандарт.
Электронная таблица, упомянутая в приложении A, имеет структуру, приведенную в таблице 2.
Таблица 2
исходный набор взаимосвязей
Номер колонки | Имя колонки | Содержащаяся информация | Формат |
1 | URI part11 Class | URI взаимосвязи | текст |
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 | Высший класс в иерархии, который допускается на левой стороне взаимосвязи (все подклассы этого суперкласса допускаются на левой стороне) | текст |
8 | Range | Высший класс в иерархии, который допускается на правой стороне взаимосвязи (все подклассы этого суперкласса допускаются на правой стороне) | текст |
Таблица 2 устанавливает:
- порядок колонок в таблице;
- имя каждой колонки, указанное в первой строке таблицы;
- описание информации в колонке;
- формат данных в колонке.
В рамках исходного набора взаимосвязей проведено различие во взаимосвязях между экземплярами классов и взаимосвязях с/между классами. Набор взаимосвязей на уровне класса является подмножеством набора взаимосвязей на уровне экземпляра.
Цель использования настоящего стандарта в качестве "упрощающего слоя" ("simplification layer") для ИСО/ТС 15926-7 заключается в повышении возможности использования комплекса стандартов ИСО 15926 практикующими инженерами. В данном случае настоящий стандарт будет являться средством достижения цели ("Stepping Stone") от простой к более детальной семантической точности в контексте шаблонов ИСО/ТС 15926-7.
Шаблоны настоящего стандарта, при необходимости, можно использовать в качестве упрощающего слоя/входного интерфейса, а также как независимую "реализацию", сочетающуюся с RDL.
Настоящий стандарт также можно использовать для создания моделей продукции, процессов или требований, используя ИСО/ТС 15926-4, но не ограничиваясь только представленным в настоящем стандарте. Также допускается интеграция с другими библиотеками.
Положения настоящего стандарта могут быть реализованы с использованием именованных RDF-графов, электронных таблиц, баз данных SQL, баз данных графов и конкретного применения программного обеспечения (с API-интерфейсами ИСО 10303).
Используемые взаимосвязи отображены на сущности ИСО 15926-2 и экземпляры ИСО/ТС 15926-4 и, в целом, рассматриваются как наиболее быстрый путь в контексте применения моделей данных ИСО 15926-2. Данное отображение (мэппинг) можно использовать для отображения информации в соответствии с настоящим стандартом в шаблоны ИСО/ТС 15926-7 или для создания новых шаблонов ИСО/ТС 15926-7.
Пример - Для иллюстрации взаимосвязи между настоящим стандартом и ИСО 15926-2 и ИСО/ТС 15926-7 приведен следующий пример, в котором полное, соответствующее ИСО 15926-2 представление свойства передатчика (см. рисунок 74), а именно информация о нем, приведено с использованием именованных RDF-графов.
по ИСО 15926-2
Ниже приведена трансляция схемы, изображенной на рисунке 74, утверждения в контексте настоящего стандарта:
3051CG | является специализацией | передатчика давления |
3051CG | имеет свойство | рабочая температура окружающей среды |
Рабочая температура окружающей среды | является специализацией | температуры окружающей среды |
Рабочая температура окружающей среды | имеет в качестве нижней границы | -40 |
Рабочая температура окружающей среды | имеет в качестве верхней границы | 85 |
Рабочая температура окружающей среды | рассчитывается в | Градусы Цельсия |
Рабочая температура окружающей среды | имеет формат | Целое число |
В таблице 3 набор этих утверждений записан в формате N-Quad W3C. Только первое из утверждений сопровождается метаданными "isCreatedBy" и "isCreatedAt".
Таблица 3
Колонки представления электронной таблицы,
содержащие исходный набор взаимосвязей
Субъект | Предикат | Объект | Именованный граф UID |
myproduct:3051CG | rdfs:subClassOf | mylibrary:PressureTransmitter | myproduct:001 |
myproduct:001 | myproduct:isCreatedBy | "John Doe" | myproduct:001 |
myproduct:001 | myproduct:isCreatedAt | "15-5-2013 12:00" | myproduct:001 |
myproduct:3051CG | myproduct:hasProperty | mylibrary: OperatingAmbientTemperature | myproduct:002 |
myproduct: OperatingAmbient Temperature | rdfs:subClassOf | mylibrary: AmbientTemperature | myproduct:003 |
myproduct: OperatingAmbient Temperature | myproduct: hasAsLowerBound | "-40" | myproduct:004 |
myproduct: OperatingAmbient Temperature | myproduct: hasAsUpperBound | "85" | myproduct:005 |
myproduct: OperatingAmbient Temperature | myproduct: isQuantifiedIn | mylibrary:Celsius | myproduct:006 |
myproduct: OperatingAmbient Temperature | myproduct: hasFormat | "xxx" xsd Integer | myproduct:007 |
ИСО 10303-233 отличается от комплекса международных стандартов ИСО 15926 по следующим аспектам:
- ИСО 10303-233 является STEP протоколом (стандарт по обмену данными моделей изделий) с AAM, ARM и AIM, осуществляющим мэппинг с помощью возможностей языка EXPRESS. ИСО 10303-233 направлен на обеспечение интероперабельности, обмен информацией и данными между компьютерами.
- Настоящий стандарт является частью комплекса международных стандартов ИСО 15926 с Библиотекой справочных данных и отдельной моделью данных, не использующей AIM или EXPRESS. Он нацелен на интеграцию информации и данных в рамках цепочки снабжения производственного объекта и обеспечение интероперабельности бизнес-партнеров, включая данные по системному проектированию.
- Могут возникнуть трудности при использовании ИСО 10303-233 напрямую для приложения, основанного на принципах ИСО 15926. Именно поэтому настоящий переносит концепции системного проектирования ИСО 10303-233 в среду ИСО 15926 посредством набора взаимосвязей настоящего стандарта, также поддерживаемых ИСО/МЭК 15288.
- Таким образом, можно использовать и другие функциональные возможности ИСО 15926 в приложениях с аспектами системного проектирования и при этом можно сделать куда больше, чем только просто отобразив все на ИСО 10303-233.
(обязательное)
Исходный набор взаимосвязей опубликован в виде электронной таблицы в формате Excel, зарегистрированной ТК 184/ПК 4/РГ 3 под именем: n2643_WG3_initial set of relationships_ISO/TS 15926-11_2014-07-07.
Доступен по следующему адресу:
/template/go.php?url=https://standards.iso.org/iso/15926/-11/
Это выполнено в соответствии с документом ПК 4 для конвенций URI (ISO TC 184/SC 4 N 2265, см. библиографию). Для технических спецификаций это означает следующую адресную структуру:
/template/go.php?url=https://standards.iso.org/iso/ts/15926/-3/ed-1/tech/reference-data/spreadsheet/
В данном случае словосочетание "reference-data" означает представление стандарта, например в OWL, электронной таблице и т.п.
Представление электронной таблицы для настоящего стандарта содержит набор взаимосвязей, который называется relationship_p11.xlsx.
Нижеуказанное положение об авторских правах применяется к набору справочных данных и включено в представление набора справочных данных.
Настоящим предоставляется разрешение, безвозмездно и на неограниченный срок, любому лицу, получающему копию набора справочных данных, использовать, копировать, модифицировать, объединять и бесплатно распределять копии набора справочных данных для разработки, внедрения, инсталляции и использования программного обеспечения на основе набора справочных данных, а также разрешение лицам, которым предоставлен набор справочных данных, поступать таким образом на следующих условиях: НАБОР СПРАВОЧНЫХ ДАННЫХ ПРЕДОСТАВЛЯЕТСЯ НА УСЛОВИЯХ ПОСТАВКИ "КАК ЕСТЬ", БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ПРЯМЫХ ИЛИ КОСВЕННЫХ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ГАРАНТИЯМИ ТОВАРНОЙ ПРИГОДНОСТИ, ПРИГОДНОСТЬЮ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ И ПАТЕНТНОЙ ЧИСТОТОЙ. НИ В КОЕМ СЛУЧАЕ ИСО ИЛИ ЛЮБОЙ ДРУГОЙ ЛИЦЕНЗИАР, КОТОРЫЙ ПРЕДОСТАВЛЯЕТ ПРАВО В СООТВЕТСТВИИ С ВЫШЕУКАЗАННЫМ РАЗРЕШЕНИЕМ ИСПОЛЬЗОВАТЬ СХЕМУ, НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА КАКУЮ-ЛИБО ПРЕТЕНЗИЮ, УЩЕРБ ИЛИ ЛЮБУЮ ДРУГУЮ ОТВЕТСТВЕННОСТЬ КАК ПРИ ВЫПОЛНЕНИИ КОНТРАКТА, ПРИ ГРАЖДАНСКОМ ПРАВОНАРУШЕНИИ, ТАК И ВО ВСЕХ ДРУГИХ СЛУЧАЯХ, ВЫТЕКАЮЩИХ В СВЯЗИ С НАБОРОМ СПРАВОЧНЫХ ДАННЫХ ЛИБО В СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ИЛИ ДРУГИМИ ТОРГОВЫМИ СДЕЛКАМИ, СВЯЗАННЫМИ С НАБОРОМ СПРАВОЧНЫХ ДАННЫХ. Дополнительно к этому любая модифицированная копия набора справочных данных должна включать следующее уведомление: ДАННЫЙ НАБОР СПРАВОЧНЫХ ДАННЫХ БЫЛ МОДИФИЦИРОВАН ПО СРАВНЕНИЮ С НАБОРОМ СПРАВОЧНЫХ ДАННЫХ, ПРИВЕДЕННЫМ В ИСО/ТС 15926-11, И НЕ ДОЛЖЕН ИНТЕРПРЕТИРОВАТЬСЯ КАК СООТВЕТСТВУЮЩИЙ ЭТОМУ СТАНДАРТУ |
(обязательное)
B.1 Общие положения
Данное приложение содержит примеры возможных синтаксических форматов методологии именованных графов RDF. Далее приведены три примера: формат TriX, формат N-Quads и электронные таблицы. Реализация настоящего стандарта с использованием одного из трех указанных форматов предоставляет гибкий механизм обмена промышленными данными.
B.2 Формат TriX
Триплеты в XML (TriX) являются сериализацией для представления триплетов RDF в XML формате. Это обеспечивает высоконормализованное единообразное XML представление RDF-графов. Преимущество TriX состоит в том, что он позволяет использовать общедоступный инструментарий XML, например XSLT, XQuery и т.д. Данный инструментарий обеспечивает доступ и позволяет оценивать структуру графа или тексты документов в формате TriX для проверки синтаксиса. Более полную информацию можно найти на сайте www.w3.org/2004/03/trix/.
Графическое представление утверждения о том, что MyCar состоит из MyEngine, приведено далее.
<TriX>
<graph>
<uri>myproject:myCarConsistOfMyEngine </uri>
<triple>
<uri>myproject:myCarConsistOfMyEngine</uri>
<uri>dc:creator</uri>
<uri>myproject:JohnDoe</uri>
</triple>
<triple>
<uri>myproject:myCarConsistOfMyEngine</uri>
<uri>dc:created</uri>
<typedLiteral datatype="xsd:dateTime" > 2013-05-5T12:00:00Z </typedLiteral>
</triple>
<triple>
<uri>myproject:myCarConsistOfMyEngine</uri>
<uri>rdf:type</uri>
<uri>part11:StatementGraph</uri>
</triple>
<triple>
<uri>myproject:MyCar</uri>
<uri>myproject:MyEngine</uri>
</triple>
</graph>
</TriX>
B.3 Формат N-Quads
Формат N-Quads является стандартом W3C, который определяет легкий для парсинга текстовый язык кодирования наборов RDF-данных (см. /template/go.php?url=https://www.w3.org/TR/2013/CR-n-quads-20131105/).
Утверждения в формате N-Quad являются последовательностью RDF-терминов, представляющих собой субъект, предикат, объект и метку (обозначение) RDF-графа-триплета и графа, чьей частью он является в наборе данных. Термины разделяются между собой символом '' (пробела). Данная последовательность заканчивается символом '.' и новой строкой (произвольно в конце документа). В таблице B.1 тот же пример приведен в формате N-Quad.
Таблица B.1
Представление именованного графа в формате N-Quad W3C
URI субъекта | URI взаимосвязи | URI объекта | URI именованного графа |
myproject:MyCarConsist OfMyEngine | dc:creator | Myproject:JohnDoe | myproject: MyCarConsistOfMy Engine |
myproject:MyCarConsist OfMyEngine | dc:created | myproject: MyCarConsistOfMy Engine | |
myproject:MyCarConsist OfMyEngine | rdf:type | myproject: MyCarConsistOfMy Engine | |
myproject:MyCar | myproject:myConsistOf | myproject: MyCarConsistOfMy Engine |
B.4 Формат "RDF expression table" в виде электронной таблицы
В таблице B.2 те же утверждения, что и в предыдущем примере, представлены в виде электронной таблицы. Таким способом определенные электронные таблицы могут быть легко трансформированы в структуру именованных графов и наоборот. Любой желающий может, например, преобразовать утверждения метаданных именованного графа в дополнительные колонки электронной таблицы (например, "автор", "создан", "изменен"). В этом примере имена субъекта, предиката и объекта представлены в электронной таблице (это может быть реализовано путем использования функции поиска/просмотра электронной таблицы).
Таблица B.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- 15T12.00:00" | myproject: MyCarConsist OfMyEngine | ||
myproject: MyCarConsist OfMyEngine | rdf:type | является типом (is of type) | StatementGraph | myproject: MyCarConsist OfMyEngine | ||
myproject:MyCar | MyCar | myproject: myConsistOf | состоит из (myConsistOf) | myproject: MyEngine | MyEngine | myproject: MyCarConsist OfMyEngine |
(справочное)
ПРИМЕРЫ ПРИМЕНЕНИЯ НАСТОЯЩЕГО СТАНДАРТА
C.1 Пример: использование настоящего стандарта для определения модели знаний о продукции
Группа из международного комитета по сжатому воздуху и смежным областям машиностроения (ICAAMC) разработала модель знаний компрессора. Модель компрессора содержит нормативную ссылку на ИСО/ТС 15926-4, и в частности на rotating_equipment.xls, к разработке которого ICAAMC была привлечена.
На рисунке C.1 представлен снэпшот данных модели знаний компрессора, который использует взаимосвязи, определенные в исходном наборе в приложении A, и информационные модели, указанные в разделе 5.
представленный в виде сущностей ИСО/ТС 15926-4
и взаимосвязей настоящего стандарта
C.2 Пример: использование настоящего стандарта для уточнения требований
Второй пример показывает способ представления традиционно изложенного требования в наборе связанных утверждений, используя методологию, описанную в настоящем стандарте. В этом случае спецификация может быть основана на Библиотеке справочных данных и наборе совместимых взаимосвязей, предоставляющих возможность однозначного обмена информацией между клиентом и контрактом.
Пример традиционного проектного требования:
"Система отопления должна состоять из теплообменника трубчатого типа, пригодного для передачи тепла насосами от масла-теплоносителя к горячей воде, трубопроводов и т.п. для подачи горячей воды к центральным аппаратам кондиционирования воздуха. Должны быть установлены два насоса для циркуляции горячей воды, каждый рассчитанный на 50% мощности".
В таблице C.1 данное требование явно выражено с помощью утверждений внутри дополнительных колонок соответствующих метаданных. Этот шаблон можно использовать для определения/сбора требований, и, при необходимости, любой желающий может преобразовать данный шаблон в структуру именованного графа в соответствии с настоящим стандартом.
Таблица C.1
Субъект | Взаимосвязь | Имеет кардинальность | Объект | Имеет модальность |
система отопления (heating system) | состоит из (consist of) | <1> | теплообменник (heat exchanger) | должен иметь (shall have) |
теплообменник (heat exchanger) | является исполнителем (is performer of) | теплообмен между двумя потоками (exchanging heat between two streams) | ||
первичный поток (primary stream) | участвует в (participates in) | теплообмен между двумя потоками (exchanging heat between two streams) | ||
вторичный поток (secondary stream) | участвует в (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) | должен иметь (shall have) | |
насос (pump) | является исполнителем (is performer of) | циркулирующий вторичный поток (circulating secondary stream) | должен иметь (shall have) | |
насос (pump) | имеет свойство (has property) | мощность насоса (pump capacity) | должен иметь (shall have) | |
мощность насоса (pump capacity) | квалифицируется как (is qualified as) | 50% полной мощности системы отопления (50% of the full heating system capacity) | должен иметь (shall have) | |
первичный поток (primary stream) | находится под ответственностью (is the responsibility of) | клиент (client) | ||
вторичный поток (secondary stream) | находится под ответственностью (is the responsibility of) | контрактор (contractor) |
C.3 Пример: использование настоящего стандарта для обмена явными данными модели продукции совместно с неструктурированными данными в документах
На рисунке C.2 приведен пример, где для обмена данными используется BIM-контейнер (например, ZIP-файл). На рисунке C.2 показан BIM-контейнер, состоящий из:
- файла заголовка, основанного на информационной модели транзакций, как показано на рисунке 68, и использующего методологию именованного графа настоящего стандарта;
- файла информационной модели, использующего методологию именованного графа настоящего стандарта;
- файлов документов (например, файлы Word или 3D-модели), которые определены в рамках информационной модели.
на основе настоящего стандарта
Любой желающий может выбрать, чем посредством информационной модели обмениваться явным образом, а также какими данными посредством документов обмениваться неявным образом. Такой подход позволяет плавно мигрировать от небольшой явной модели данных о продукции (например, структурная декомпозиция системы), ссылающейся на традиционные документы, к большей явной модели данных о продукции с минимальным количеством документов (или их отсутствием) в качестве носителя неявной информации.
BIM-часть содержит ссылки на RDL (посредством взаимосвязи "is of type" (является типом)). Также присутствуют представления, определенные в BIM-части из документов, которые положены в тот же контейнер (отражаются в документальной части).
C.4 Пример: использование настоящего стандарта для построения системы управления данными жизненного цикла продукции
Подход с использованием именованных графов, как описано в настоящем стандарте, можно использовать для построения системы управления данными жизненного цикла продукта.
Хранилища триплетов и базы данных графов организованы таким образом, что они, благодаря своим внутренним характерным особенностям, "понимают" структуру именованных графов. Реализовать положения настоящего стандарта в этой среде относительно легко.
Реализация в среде, не основанной на триплетах, требует, как правило, использования структуры базы данных, аналогичной показанной на рисунке C.3. Этот рисунок также относится и к колонкам в формате N-Quad, как это описано в приложении B, при комбинировании функциональности хранилища данных и информационного обмена, оба из которых основаны на именованных RDF-графах.
именованного графа в не основанной на триплетах среде,
например на традиционной системе управления
реляционными базами данных (RDBMS)
(справочное)
С ПОМОЩЬЮ ТРИПЛЕТОВ
Из-за сложности существующих стандартов различные (промышленные) группы начали разрабатывать упрощенную методологию моделирования знания о продукции либо инициировать и организовывать в своих организациях работы по системному проектированию. Для достижения этой цели некоторые организации воспользовались формализованным естественным языком, на основе принципов ИСО 10303-221 и ИСО 15926-2, который стал известен как "Gellish" (см. [18]). Gellish доказал возможность своего практического применения на практике в силу эффективности полученных результатов.
Gellish - это мощный, общедоступный и свободно распространяемый язык и онтология для хранения и обмена электронными данными в нейтральном и системно-независимом виде. В течение длительного времени этому направлению не хватало стандартной модели данных, как и единообразного языка описания, предназначенного для пользователей банков данных. Для решения этой проблемы предлагались различные варианты. Однако они либо имели ограниченную область применения, взаимную несовместимость, либо были сложными в применении. С другой стороны, эти концепции с трудом совмещались друг с другом, что усложняло информационный обмен с различными поставщиками данных. Gellish предлагает интегральное решение этой проблемы, а также базу знаний, поскольку они довольно похожи для реализации. Язык Gellish может заменить модели данных и обеспечивает расширяемую онтологию со стандартными справочными данными для возможности настройки и гармонизации систем.
Словарь/таксономия/онтология на основе языка Gellish могут быть использованы, помимо прочего, для стандартизации контента существующих систем, например таких, как данные в системах проектирования, ERP-системах и системах снабжения/закупок. Он также позволяет интегрировать данные из различных источников, таких как данные из различных инженерных приложений и приложений электронного бизнеса. Например, он позволяет описывать каталоги продукции независимым от конкретной системы образом или описывать требования к продукции, спецификации оборудования, техническое состояние оборудования, бизнес-процессы и бизнес-транзакции таким образом, чтобы ими можно было обмениваться между различными системами и различными участниками без необходимости преобразования или трансляции данных. Использование данного языка поддерживается на общедоступном и бесплатном веб-сайте по адресу: /template/go.php?url=https://sourceforge.net/projects/gellish/.
Gellish использует таблицы данных, которые являются сводными таблицами на основе структуры объект-отношение-объект, что является достаточным для представления любого вида фактографической информации. Таблицы данных Gellish также определяют исчерпывающий набор вспомогательных фактов, таких как статус, автор, характеристики времени, источник базовых фактов, уникальные идентификаторы, назначение и адресат.
Это оказалось очень полезным на практике, например в части того, что компьютер должен хранить и обрабатывать выражения, а также управлять процессами изменений. Колонки таблицы данных Gellish стандартизованы (см. [18]). Различные подмножества таблицы данных Gellish могут распознаваться. В простейшей версии (являющейся частью полной версии) включены только утверждения.
Таблица D.1 - это пример основной части простой таблицы данных Gellish. Эта версия легче воспринимаема для чтения человеком. Каждая строка таблицы содержит утверждение, которое выражает некоторый факт. Принцип методологии триплетов, где объект с правой стороны имеет отношение (взаимосвязь) к объекту с левой стороны (главный факт), очень похож на структуру RDF-триплета. Триплет состоит из субъекта, предиката (отношения) и объекта (таблица D.1).
Таблица D.1
Объект с левой стороны (RDF:субъект) | Взаимосвязь (RDF:предикат) | Объект с правой стороны (RDF:объект) |
Машина | является подтипом | транспортное средство |
Колесо | может быть частью | машина |
Взаимосвязь между Gellish и именованными RDF-графами приведена на рисунке D.1.
На рисунке D.2 проиллюстрирован факт на языке Gellish.
(справочное)
НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ
Таблица ДА.1
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ISO/TS 15926-4 | IDT | ГОСТ Р 55340-2014/ISO/TS 15926-4:2007 "Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия. Часть 4. Исходные справочные данные" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: - IDT - идентичный стандарт. | ||
[1] | ISO 704:2009 Terminology work. 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/IEC 11578:1996 Information technology. Open Systems Interconnection. Remote Procedure Call (RPC) (Информационные технологии. Взаимодействие открытых систем. Вызов удаленных процедур) |
[8] | ISO/IEC/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; /template/go.php?url=https://www.w3.org/RDF/ |
[15] | W3C:2014; Именованные графы /template/go.php?url=https://www.w3.org/2004/03/trix/rdfg-1/ |
[16] | Ссылка на язык OWL веб-онтологии, W3C Рекомендация 2004-02-10. Имеется во Всемирной сети Интернет (WWW): /template/go.php?url=https://www.w3.org/TR/2004/REC-owl-ref-20040210/ |
[17] | Berners-Lee T. Cool URIs don't change. Имеется во Всемирной сети Интернет (WWW): /template/go.php?url=https://www.w3.org/TR/cooluris/ |
Gellish, Общий расширяемый онтологический язык - Конструкция и применение Универсальной структуры данных, д-р. Ir. Andries van Renssen, ISBN 904072597-7, Пресса Политехнического института в Делфте, 2005: /template/go.php?url=https://www,gellish.net/downloads (pdf) или /template/go.php?url=https://www.iospress.nl/book/gellish-a-generic-extensible-ontological-language/ (печатная копия) | |
[19] | ИСО/ТК 184/ПК 4 N 2265, Унифицированный идентификатор ресурса (URI), определяемый с помощью стандарта ПК 4 |
[20] | ИСО/ТК 184/ПК 4/РГ 1 doc.3.2.2.1, Общая справочная модель AEC (GARM), отчет TNO BI-88150, октябрь 1988 |
[21] | Дублинский набор основополагающих элементов метаданных, Версия 1.1 /template/go.php?url=https://dublincore.org/documents/2012/06/14/dces/ |
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/32/gost_73490.html
На правах рекламы:
|
© Антон Серго, 1998-2026.
|
Разработка сайта |
|