ПНСТ 930-2024 Информационные технологии. Интернет вещей. Совместимость систем интернета вещей. Часть 3. Семантическая совместимость

Обложка ПНСТ 930-2024 Информационные технологии. Интернет вещей. Совместимость систем интернета вещей. Часть 3. Семантическая совместимость
Обозначение
ПНСТ 930-2024
Наименование
Информационные технологии. Интернет вещей. Совместимость систем интернета вещей. Часть 3. Семантическая совместимость
Статус
Принят
Дата введения
2025.01.01
Дата отмены
2028.0101.01
Заменен на
-
Код ОКС
35.110

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

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

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

пнет

930—

2024

(ИСО/МЭК 21823-3:

2021)

Информационные технологии ИНТЕРНЕТ ВЕЩЕЙ Совместимость систем интернета вещей

Часть 3

Семантическая совместимость

[ISO/IEC 21823-3:2021, Internet of things (loT) — Interoperability for loT systems — Part 3: Semantic interoperability, MOD]

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

Москва

Российский институт стандартизации 2024

ПНСТ 930—2024

Предисловие

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

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

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

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 21823-3:2021 «Интернет вещей (1оТ). Совместимость систем интернета вещей. Часть 3. Семантическая совместимость» [ISO/IEC 21823-3, Internet of Things (loT) — Interoperability for loT systems — Part 3: Semantic interoperability, MOD] путем изменения отдельных фраз (слов, значений показателей, ссылок), которые выделены в тексте курсивом. Внесение указанных технических отклонений направлено на учет потребностей национальной экономики Российской Федерации.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5—2012 (пункт 3.5)

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

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 107045 Москва, Сретенский тупик, д. 3, стр. 1, и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.

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

©Оформление. ФГБУ «Институт стандартизации», 2024

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

II

ПНСТ 930—2024

Содержание

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

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

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

4 Сокращения.........................................................................2

5 Процесс обеспечения семантической функциональной совместимости ИВ......................3

5.1 Общие положения.................................................................3

5.2 Требования к процессу обеспечения семантической совместимости ИВ....................3

5.3 Модели семантической функциональной совместимости ИВ..............................5

5.4 Рекомендации для семантической функциональной совместимости ИВ.....................7

6 Жизненный цикл семантической функциональной совместимости ИВ.........................13

6.1 Требования к жизненному циклу....................................................13

6.2 Модель жизненного цикла.........................................................17

6.3 Руководство по реализации жизненного цикла.........................................18

Приложение А (справочное) Руководство по обучению в области семантической функциональной совместимости ИВ........................................................21

Приложение В (справочное) Руководство по разработке семантической совместимости ИВ........24

Приложение С (справочное) Руководство по управлению жизненным циклом семантической совместимости ИВ........................................................26

Приложение D (справочное) Онтологическая спецификация типовой архитектуры ИВ.............28

Приложение Е (справочное) Онтологии, существующие в области ИВ..........................32

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

III

ПНСТ 930—2024

Введение

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

Функциональная совместимость ИВ определяется как успешное взаимодействие между сущностями, указанными в ГОСТ Р 70924, например между службами ИВ, предоставляемыми разными поставщиками служб ИВ. Функциональная совместимость ИВ обеспечивается путем использования аспектной модели, определенной в ПНСТ 644, включающей пять аспектов: транспортный, синтаксический, семантический, поведенческий и аспект политики.

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

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

Как показано на рисунке 1:

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

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

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

Рисунок 1 — Семантическая функциональная совместимость ИВ

Семантическая функциональная совместимость обеспечивается путем использования метаданных или описаний данных. В ИТ-системах подход предоставления данных и описаний широко используется, например:

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

Ь) для отображения содержимого записи базы данных используются структуры записей.

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

IV

ПНСТ 930—2024

Рисунок 2 — Использование метаданных при обеспечении семантической функциональной совместимости

Метаданные обеспечивают общее понимание обмениваемых данных для систем ИВ. На рисунке 3 показано, как метаданные описывают (правый столбец) и определяют (левый столбец) значение данных для конкретной комнатной температуры.

Физическая сущность

Свойство

Данные

UUID или L4F9R22

Температура, К

Метаданные датчика L4F9R22

Тип данных

Действительное число с плавающей точкой

Измеренное значение

0100001110010011

0101001100110011

(294,65)

Идентификатор

UUID или L4F9R22

- выходные данные по запросу метаданных датчика;

- выходные оперативные данные датчика (ID и значение);

- метаданные датчика

Рисунок 3 — Информативность данных, описанных метаданными

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

V

ПНСТ 930—2024

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

Настоящий стандарт определяет также методы и способы обеспечения семантической совместимости систем ИВ. Раздел 5 определяет процесс обеспечения семантической функциональной совместимости ИВ. Раздел 6 определяет управление жизненным циклом семантической функциональной совместимости ИВ.

Справочные приложения содержат дополнительную информацию и рекомендации. Приложения А, В и С содержат рекомендации по изучению семантической функциональной совместимости ИВ, разработке семантической функциональной совместимости ИВ и управлению жизненным циклом семантической функциональной совместимости ИВ, соответственно. Приложение D содержит онтологическую спецификацию типовой архитектуры ИВ, определенную в ГОСТ Р 70924. Приложение Е содержит существующие онтологии, применимые для семантической функциональной совместимости ИВ.

ПНСТ 930—2024 (ИСО/МЭК 21823-3:2021)

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

Информационные технологии

ИНТЕРНЕТ ВЕЩЕЙ

Совместимость систем интернета вещей

Часть 3

Семантическая совместимость

Information technology. Internet of Things (loT). Interoperability for loT systems.

Part 3. Semantic interoperability

Срок действия — с 2025—01—01 до 2028—01—01

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

Настоящий стандарт определяет основные концепции семантической функциональной совместимости систем ИВ, являющейся частью аспектной модели функциональной совместимости в соответствии с ПНСТ 644—2022, в том числе:

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

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

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

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

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

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

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

ГОСТ Р 57193 Системная и программная инженерия. Процессы жизненного цикла систем

ГОСТ Р 70924 (ИСО/МЭК 30141:2018) Информационные технологии. Интернет вещей. Типовая архитектура

ГОСТ Р ИСО/МЭК 29100 Информационная технология. Методы и средства обеспечения безопасности. Основы обеспечения приватности

ПНСТ 644—2022 (ИСО/МЭК 21823-1:2019) Информационные технологии. Интернет вещей. Совместимость систем интернета вещей. Часть 1. Структура

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

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

1

ПНСТ 930—2024

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

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

В настоящем стандарте применены термины по ПНСТ 644—2022, а также следующие термины с соответствующими определениями:

3.1

метаданные (metadata): Данные, которые определяют и описывают другие данные.

[ГОСТ Р ИСО/МЭК 11179-3—2012, 3.2.18]

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

Примечание — Данная спецификация должна быть доступна в электронном виде.

4 Сокращения

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

API — программный интерфейс приложения (Application Programming Interface);

СоАР — протокол ограниченного приложения (Constrained Application Protocol);

ETSI — Европейский институт телекоммуникационных стандартов (European Telecommunications Standards Institute);

HTTP — протокол передачи гипертекста (Hypertext Transfer Protocol);

IDE — интегрированная среда разработки (Integrated Development Environment);

JSON-LD — формат описания контента с помощью объектов словаря связанных данных (JSON Linked Data);

LOV4loT — связанные открытые словари для интернета вещей (Linked Open Vocabularies for Internet of Things);

OCF — отраслевая организация по разработке стандартов, фонд «Открытая связь» (Open Connectivity Foundation);

OWL — язык описания онтологий для семантической паутины (Web Ontology Language);

OWL-S — онтология, построенная поверх языка OWL;

PKI — инфраструктура открытых ключей (Public Key Infrastructure);

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

RDFS — схема RDF (RDF Schema);

SAREF — справочник по умным приложениям (Smart Applications REFerence);

SPARQL — язык запросов к данным, представленным по модели RDF (SPARQL Protocol and RDF Query Language);

SSN — семантическая сенсорная сеть (Semantic Sensor Network);

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

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

URL — унифицированный указатель ресурса (Uniform Resource Locators);

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

XMPP — расширяемый протокол обмена сообщениями и информацией о присутствии (Extensible messaging and presence protocol);

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

ИИ — искусственный интеллект;

2

ПНСТ 930—2024

ИКТ — информационно-коммуникационные технологии;

ИТ — информационные технологии;

ИВ — интернет вещей;

2D — двумерный (2-dimensional).

5 Процесс обеспечения семантической функциональной совместимости ИВ

5.1 Общие положения

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

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

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

Настоящий стандарт предоставляет инженерам-онтологам и инженерам систем ИВ требования и спецификации методов для подготовки и проектирования семантической функциональной совместимости (рисунок 4).

Рисунок 4 — Цели настоящего стандарта

Настоящий стандарт определяет два типа требований:

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

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

5.2 Требования к процессу обеспечения семантической совместимости ИВ

Должны быть проведены следующие процессы:

- создание информационной модели данных;

- интеграция функциональности семантической совместимости;

- инженерная поддержка семантической функциональной совместимости.

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

3

ПНСТ 930—2024

Таблица 1 — Требования к процессу обеспечения семантической совместимости ИВ

Процессы

Требование

Обоснование

Результат

Создание информационной модели данных

Необходимо провести сбор общих знаний с использованием общих онтологий

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

Информационная модель данных на основе собранных и задокументированных общих знаниях о системе ИВ

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

Системы ИВ могут относиться к конкретных предметным областям, таким как транспорт, энергетика, здравоохранение

Информационная модель данных для системы ИВ в конкретной предметной области

Необходимо провести сбор межпредметных знаний с помощью межпредметных онтологий

Системы ИВ могут охватывать несколько предметных областей. Например, система ИВ для электромобилей относится к области транспорта и энергетики

Межпредметная информационная модель данных для системы ИВ

Интеграция функциональности семантической совместимости

Должна быть разработана функциональность системы ИВ для обмена информацией о функциональной совместимости устройств ИВ

Системы ИВ могут использовать различные параметры совместимости, включая технические параметры (например, драйверы, протоколы) и семантические параметры (например, функциональность приложений). Обмен параметрами совместимости с использованием метаданных может происходить до номинальной работы устройства. Метаданные могут быть представлены в виде схемы или подсхемы с использованием OWL, XML или JSON-LD.

Обмен может включать прокси-сервер, если устройство ИВ не может предоставить функциональность напрямую

Функциональность системы ИВ для обмена информацией о функциональной совместимости устройств

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

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

Согласование может включать прокси-сервер, если устройство ИВ не может предоставить функциональность напрямую

Функциональность системы ИВ для согласования профилей совместимости

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

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

Устройство ИВ, обеспечивающее общую функциональность совместимости

4

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

ПНСТ 930—2024

Процессы

Требование

Обоснование

Результат

Инженерная поддержка семантической функциональной совместимости

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

Инженерам необходимы вспомогательные инструменты, например, для обнаружения и выбора онтологий, отображения, выравнивания, слияния и интеграции

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

5.3 Модели семантической функциональной совместимости ИВ

Семантическая функциональная совместимость ИВ может быть описана двумя моделями: моделью процесса и моделью использования. Модель процесса определяет создание функциональности семантической функциональной совместимости. Модель использования определяет использование и обмен семантической информации.

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

Рисунок 5 — Модель процесса обеспечения семантической функциональной совместимости ИВ

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

5

ПНСТ 930—2024

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

Ь) Создание функциональности семантической совместимости: целью данного процесса является создание функциональности семантической совместимости и адаптация семантической информации к требуемому представлению. Функциональность включает:

1) использование режимов устройства;

2) возможность согласования и рассуждений;

3) общую совместимость.

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

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

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

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

Использование семантической информации основано на модели, показанной на рисунке 6.

Рисунок 6 — Модель использования семантической информации

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

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

6

ПНСТ 930—2024

Пример — Модель температуры, связанная с абстрактным датчиком температуры ИВ;

- конкретную модель компонента или системы ИВ. Конкретная информация о функциональной совместимости связана с конкретным компонентом или системой ИВ в эксплуатации.

Пример — Конкретная модель температуры, связанная с физическим датчиком температуры;

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

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

5.4 Рекомендации для семантической функциональной совместимости ИВ

5.4.1 Рекомендации по сбору семантических значений

Сбор семантических значений достигается при помощи процесса создания семантического знания, как показано на рисунке 5, и включает использование следующих знаний:

- общие онтологии ИВ, которые относятся к общим понятиям, таким как понятия архитектуры или структуры. Онтологии могут быть основаны на стандартах ИВ, таких как ГОСТ Р 70924, или на спецификациях отображения (см. [2]);

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

- предметные онтологии ИВ. Например, в области энергетики может быть использована онтология управления энергопотреблением [3]. Предметные онтологии, например, могут быть созданы в области умного города (см. [4]), умного производства (см. [5]) или в области сельского хозяйства (см. [6]).

На рисунке 7 показан пример структурированного представления знаний о семантической совместимости, которое включает:

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

- предметные онтологии, связанные с приложениями, такие как онтологии здравоохранения, транспорта, энергетики или сельского хозяйства. Для структурирования знаний о семантической совместимости может быть использовано множество существующих предметных онтологий, например LOV4loT [8].

Инфраструктура общих и межпредметных онтологий

Архитектура

Безопасность \

Датчик

Энергетика

.Здания'й"’Ь'’ .сооружения

Здравоохранение

Транспорт'

Сельское хозяйство

Онтологая

Приложения предметных онтологий

Рисунок 7 — Пример структурированного представления знаний

7

ПНСТ 930—2024

Примечание — Онтологии могут быть представлены в виде троек. На рисунке 7 онтологии представлены в виде трех связанных кругов.

Онтологии строятся с использованием семантических веб-языков, таких как RDF [8], RDFS [9] и OWL [10], запросы к ним проводятся с помощью языка запросов к данным SPARQL [77].

RDF является базовым веб-языком, основанным на триплетах «субъект — предикат — объект». Например, «температура равна 39»: субъект — «температура», предикат — «есть», объект — «39».

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

Язык веб-онтологий OWL обогащает RDFS, позволяя создавать новые классы и новые отношения между классами для описания предметной области (например, в области ИВ может быть добавлено новое понятие «датчика»).

Доступ к триплетам или их запрос проводится с помощью языка запросов SPARQL для взаимодействия с графами RDF, RDFS и OWL.

Иерархия языков, называемая также семантическим веб-слоеным пирогом, определена Консорциумом Всемирной паутины (W3C) [72].

Представление для обмена информацией называется набором сериализованных данных, который является компьютерным представлением набора семантических данных. Сериализация представляет собой процесс перевода структуры в последовательность байтов, которую можно хранить и/или передавать. Примерами методов такой сериализации являются OWL и JSON-LD [73].

5.4.2 Рекомендации по интеграции функциональности семантической функциональной совместимости

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

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

1) целью режима настройки является определение рабочих возможностей устройства ИВ. Описание таких возможностей основано на онтологиях и может быть использовано устройствами для информирования других систем ИВ о возможностях устройства. Описание включает параметры технического уровня (например, драйверы, протоколы, безопасность, качество обслуживания, качество данных) и параметры семантического уровня (например, возможности обработки, права доступа, возможности приложений). Онтология устройства используется для информирования других подключенных систем ИВ с целью интерпретации полученных данных. Например, датчик температуры имеет такие атрибуты, как диапазон, точность, время срабатывания и т. д. В общедоступных репозиториях, таких как LOV4loT [7] или SSN [74], [75], представлено множество описаний онтологий датчиков;

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

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

с) способность общей совместимости устройства ИВ. Перед началом работы подсистема связи устройств ИВ должна быть настроена для включения всех компонентов, согласованных для достижения функциональной совместимости. Во время операций может проводиться обмен семантическими описаниями. Как показано на рисунке 6, существует иерархия трех представлений: абстрактное представление, конкретное представление и обмениваемая информация. На рисунке 8 показан пример датчика температуры ИВ, реализованного с использованием типовой архитектуры в соответствии с ГОСТ Р 70924'.

8

ПНСТ 930—2024

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

2) используется конкретное представление датчика температуры ИВ. Данное представление содержит фактическую информацию. Примером формата представления является представление графов RDF. Графы RDF структурированы в триплеты, доступ к которым или запрос которых можно осуществить с использованием языка SPARQL;

3) представление обмениваемой информации, доступной для компьютерной обработки, называется набором сериализованных данных. Сериализация представляет собой процесс перевода структуры в последовательность байтов, которые можно хранить и/или передавать. Примерами методов сериализации являются OWL/XML и JSON-LD.

Рисунок 8 — Пример использования семантической информации для датчика температуры

5.4.3 Руководство по проектированию семантической функциональной совместимости

5.4.3.1 Общие положения

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

9

ПНСТ 930—2024

Примечания

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

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

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

- обнаружение онтологий (см. 5.4.3.2);

- интеграция данных на основе онтологий (см. 5.4.3.3);

- преобразование онтологий, такое как отображение онтологий, выравнивание онтологий, слияние онтологий и интеграция онтологий (см. 5.4.3.4).

5.4.3.2 Обнаружение онтологий

Обнаружение онтологий — это процесс доступа к эксплуатируемым онтологиям и их использования для семантической функциональной совместимости. Обнаружение может проводиться на этапе создания знаний о семантике (см. рисунок 5), а также позднее во время настройки режима устройства. Доступны репозитории онтологий, например [7], [16], [17], в которых используются различные языки онтологии (семантической сети), такие как RDFS или OWL.

5.4.3.3 Интеграция данных на основе онтологий

Интеграция данных на основе онтологий использует онтологии для обеспечения функциональной совместимости данных путем объединения данных или информации из нескольких разнородных источников. Данные из нескольких источников характеризуются следующими типами неоднородности [18]'.

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

- структурная неоднородность: различия в исходной модели или структуре для хранения данных;

- семантическая неоднородность: различия в интерпретации значения данных;

- системная неоднородность: различия, происходящие из разных операционных систем и аппаратных платформ.

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

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

Ь) модель запроса: в некоторых системах запрос формулируется с использованием онтологии как глобальной схемы запроса. Формулировка запроса — это процесс, в ходе которого исходный запрос по ключевому слову, выданный пользователем, преобразуется в структурированное представление запроса для поисковой системы. Как правило, запрос информации проводится с использованием языка SPARQL;

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

К приложениям интеграции данных на основе онтологий применяют три основных подхода:

1) единая онтология: в качестве глобальной базовой модели в системе используют единую онтологию;

10

ПНСТ 930—2024

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

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

5.4.3.4 Преобразование онтологий

5.4.3.4.1 Общие положения

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

Преобразование онтологий — это процесс, который устраняет различия между отдельными онтологиями для достижения семантической функциональной совместимости путем выравнивания, сопоставления, слияния и других необходимых операций. Отображение онтологий — это процесс нахождения пар ресурсов из разных онтологий, которые можно считать равными по смыслу. Как правило, в качестве входных данных для различных подходов к преобразованию онтологий используется значение подобия в диапазоне [0; 1].

5.4.3.4.2 Отображение онтологий

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

Рисунок 9 — Пример отображения онтологий

5.4.3.4.3 Выравнивание онтологий

Выравнивание онтологий — это процесс приведения двух или более онтологий во взаимное согласие, что делает их непротиворечивыми и связными. Выравнивание онтологий похоже на отображение онтологий, но использует более значительные отношения между понятиями онтологии, такие как «часть» (partOf) и «содержит» (subsumes). На рисунке 10 показан пример выравнивания онтологий.

11

ПНСТ 930—2024

Рисунок 10 — Пример выравнивания онтологий

5.4.3.4.4 Слияние онтологий

Слияние онтологий — это процесс создания одной онтологии из двух или более исходных онтологий с перекрывающимися понятиями или определениями. В процессе слияния объединенная онтология создается с нуля, объединяя все исходные онтологии. На рисунке 11 показан пример слияния онтологий.

12

Рисунок 11 — Пример слияния онтологий

ПНСТ 930—2024

5.4.3.4.5 Интеграция онтологий

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

Рисунок 12 — Пример интеграции онтологий

6 Жизненный цикл семантической функциональной совместимости ИВ

6.1 Требования к жизненному циклу

Организации, разрабатывающие системы ИВ, должны осуществлять следующие виды деятельности:

- управление периметром семантической функциональной совместимости, т. е. требуемым объемом знаний;

- управление проектированием семантической функциональной совместимости;

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

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

13

ПНСТ 930—2024

Таблица 2 — Требования жизненного цикла

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

Требования

Обоснование

Результирующий рабочий продукт

Управление периметром семантической функциональной совместимости

Определение периметра знаний

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

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

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

Описание метода спецификации периметра знаний. Спецификация периметра знаний используемых онтологий

Управление проектированием семантической совместимости

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

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

Разделение ответственности заинтересованных сторон — это принцип разделения объекта проектирования на отдельные элементы, чтобы каждый элемент касался отдельной задачи.

Практика создания онтологий для функциональной совместимости требует:

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

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

Например, разработка спецификации семантической функциональной совместимости в здравоохранении может включать экспертов по ИКТ в области здравоохранения, экспертов по семантической функциональной совместимости, экспертов по безопасности и приватности, а также пользователей (пациентов, средний медицинский персонал)

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

Онтологии, полученные в результате совместного создания и модульного проектирования

14

ПНСТ 930—2024

Продолжение таблицы 2

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

Требования

Обоснование

Результирующий рабочий продукт

Управление проектированием семантической совместимости

Применение принципа модульного проектирования онтологий

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

- используют самодостаточные знания,

- могут быть спроектированы, использованы и обслужены в автономном режиме;

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

- могут быть использованы повторно.

На рисунке 13 показан пример модульного проектирования, в котором:

- онтологии энергетики и онтологии электромобилей структурированы в субонтологии (обще-доступые и необщедоступные),

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

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

Управление результирующими рабочими продуктами семантической совместимости

Оценка зрелости онтологий

Практика оценки зрелости спецификации включает два аспекта:

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

- готовность спецификации, которая измеряет зрелость спецификации функциональной совместимости.

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

Описание метода, используемого для оценки зрелости онтологии.

История развития зрелости онтологии

Документирование и поддержка онтологий

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

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

Описание подхода к документации и поддержке.

Репозиторий поддерживаемых онтологий

15

ПНСТ 930—2024

Окончание таблицы 2

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

Требования

Обоснование

Результирующий рабочий продукт

Управление результирующими рабочими продуктами семантической совместимости

Документирование и поддержка онтологий

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

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

Описание подхода к документации и поддержке. Репозиторий поддерживаемых онтологий

Область энергетики

Область электромобилей

16

Необщедоступный модуль

Общедоступный модуль

Общедоступный модуль

Необщедоступный модуль

Новый модуль

Межпредметная спецификация по семантической функциональной совместимости

Рисунок 13 — Пример модульного проектирования

Область энергетики

Область электромобилей

ПНСТ 930—2024

Необщедоступный модуль

Общедоступный модуль

Общедоступный модуль

Необщедоступный модуль

Новый модуль

Межпредметная спецификация по семантической функциональной совместимости

^Готовность онтологии: например, средняя

Готовность спецификации: например, низкая

Рисунок 14 — Пример результата оценки зрелости функциональной совместимости

6.2 Модель жизненного цикла

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

Пример использования модели жизненного цикла:

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

- инженер систем ИВ:

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

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

17

ПНСТ 930—2024

Рисунок 15 — Модель жизненного цикла семантической функциональной совместимости

6.3 Руководство по реализации жизненного цикла

6.3.1 Рекомендации по жизненному циклу онтологий

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

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

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

- этап проверки непротиворечивости онтологии: проверка того, что онтология правильно сформирована и непротиворечива;

- этап согласования онтологии: обеспечение согласия экспертов предметной области с понятиями и отношениями, отраженными в онтологии;

- этап публикации онтологии: публикация, использование и поддержка онтологии.

Рисунок 16 — Пример модели жизненного цикла онтологии

6.3.2 Рекомендации по жизненному циклу семантической функциональной совместимости

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

18

ПНСТ 930—2024

- этап определения требований: определение требований спецификации функциональной совместимости;

- этап спецификации: предоставление спецификации;

- подтверждение согласия: достижение согласия по спецификации;

- публикация: публикация спецификации функциональной совместимости.

Рисунок 17 — Пример жизненного цикла спецификации функциональной совместимости

Интеграция семантических описаний в спецификацию функциональной совместимости основана на онтологиях:

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

Ь) семантическое описание может быть ориентировано на разные семантические элементы:

1) информационные онтологии (например, семантика информации, содержащейся в блоке данных протокола);

2) онтологии взаимодействия (например, семантика протокола);

3) онтологии функциональности (например, семантическое описание профиля);

4) онтологии шаблонов (например, семантическое описание парадигмы «публикация-подписка», семантическое описание механизма обнаружения служб);

5) онтологии архитектуры (например, семантическое описание особенностей архитектуры).

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

- жизненный цикл спецификации функциональной совместимости;

- жизненный цикл онтологии архитектуры;

- жизненный цикл онтологии протокола;

- жизненный цикл онтологии здравоохранения.

6.3.3 Рекомендации по жизненному циклу системы ИВ

Проектирование интероперабельной системы ИВ направлено на интеграцию функциональной совместимости в процессы жизненного цикла системы ИВ.

ГОСТ Р 57193 определяет жизненный цикл системы как «абстрактную функциональную модель, которая представляет собой осмысление потребностей в системе, ее реализации, эксплуатации, развитии и списании». Жизненный цикл системы определен как набор процессов. Процесс описывается в соответствии с его целью, результатом и действиями. ГОСТ Р 57193 определяет тридцать процессов, разделенных на четыре категории:

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

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

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

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

19

ПНСТ 930—2024

Интеграция функциональной совместимости зависит от контекста:

1) система ИВ может быть основана на существующей спецификации функциональной совместимости или на новой спецификации, разработанной для системы;

2) спецификация может быть представлена на синтаксическом или на семантическом уровне;

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

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

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

- жизненный цикл спецификации функциональной совместимости бытовой техники.

20

ПНСТ 930—2024

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

Руководство по обучению в области семантической функциональной совместимости ИВ

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

Таблица А.1 — Пример обучающей программы в области семантической функциональной совместимости ИВ

Цель

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

Результаты обучения

По окончании обучения инженер систем ИВ должен уметь:

- представлять понятия системы ИВ с использованием онтологий (например, датчиков);

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

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

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

Формат

Предусматривается два формата обучения:

- инженеры ИВ разрабатывают системы ИВ при поддержке инженеров-онтологов;

- инженеры ИВ приобретают навыки в области разработки онтологий

Предварительные условия

Инженер ИВ должен быть знаком с проектированием систем ИВ. Например, инженер может иметь навыки в области инженерной практики с использованием ГОСТ Р 70924 и ГОСТ Р 57193

В таблице А.2 приведен пример содержания курса на основе обучающей программы.

Таблица А.2 — Содержание курса обучения в области семантической функциональной совместимости

Секция

Описание

Цели семантической совместимости ИВ

Содержание

Объяснение целей семантической совместимости ИВ:

- сбор смысловых значений;

- интеграция функциональности семантической совместимости;

- инженерная практика в области семантической совместимости

Пример обучающего материала

Настоящий стандарт (раздел 5). Рекомендации [7], [79], [20], [21]

Варианты использования и выбор формата курса

Содержание

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

Выбор формата курса:

- практика совместной разработки, т. е. совместной работы инженера систем ИВ и инженера-онтолога;

- практика разработки, т.е. разработки онтологии инженером систем ИВ

Пример обучающего материала

Материал из области проектирования систем ИВ (см. также [22])

21

ПНСТ 930—2024

Продолжение таблицы А. 2

Секция

Описание

Первая онтология

Содержание

Данная секция предполагает ручной труд. Инженер систем ИВ определяет понятия и отношения рассматриваемого варианта использования

Пример обучающего материала

Материал из области проектирования систем ИВ

Первая представленная онтология

Содержание

Объяснение представления онтологий (например, триплетов).

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

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

Пример обучающего материала

Схемы представления, такие как RDF, RDFS и OWL [23], [24]

Первое правило

Содержание

Данная секция предполагает ручной труд. Инженер ИВ определяет правила для реализации (например, «если температура ниже 10 °C, то активируется система отопления»)

Пример обучающего материала

Материал из области проектирования систем ИВ

Первое представленное правило

Содержание

Объяснения представления правил (например, правила, итоговый API). В случае совместной разработки инструктор представляет среду разработки, основанную на правилах, и реализует представление правила.

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

Пример обучающего материала

Среды разработки, такие как Apache Jena* [25]

Первое семантическое действие

Содержание

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

Пример обучающего материала

Информация о среде разработки, используемой инженером систем ИВ

Первое реализованное семантическое действие

Содержание

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

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

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

Пример обучающего материала

Механизм логического вывода Apache Jena [26]

1) Apache Jena — торговая марка продукта, поставляемого компанией Apache Software Foundation. Данная информация дана для удобства пользователей настоящего стандарта и не является рекомендацией.

22

Окончание таблицы А. 2

ПНСТ 930—2024

Секция

Описание

Первая семантическая аннотация для функциональной совместимости

Содержание

Объяснение необходимости семантической аннотации для обеспечения функциональной совместимости.

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

Пример обучающего материала

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

Первая реализация семантической аннотации для функциональной совместимости

Содержание

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

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

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

Пример обучающего материала

Документация по рабочим продуктам семантической аннотации, используемым в среде разработки (например, Jena).

Обучающие материалы по семантической аннотации [27]

Интеграция в процессы жизненного цикла системы ИВ

Содержание

Объяснение методологии разработки онтологий и их интеграции в процессы жизненного цикла системы ИВ.

Объяснение взаимосвязи между жизненным циклом онтологии, жизненным циклом функциональной совместимости и жизненным циклом системы ИВ.

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

Пример обучающего материала

См. [24], [28], [34].

По вопросам жизненного цикла см. настоящий стандарт и ГОСТР 57193

23

ПНСТ 930—2024

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

Руководство по разработке семантической совместимости ИВ

В.1 Разработка функциональности семантической функциональной совместимости

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

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

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

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

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

В.2 Этапы разработки

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

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

Таблица В.1 — Этапы разработки семантической функциональной совместимости ИВ

Этапы

Описание

Этап 1

Какова цель и требования к функциональной совместимости?

Этап 2

Кто является вовлеченными сторонами (например, организации)?

Какие системы задействованы (например, оконечные ИТ-точки, оконечные точки ИВ)? Какие механизмы используются для идентификации и аутентификации цифровых сторон (например, сертификаты и PKI)?

Этап 3

Какая информация должна быть передана (например, формат, частота, качество, идентификатор)?

Этап 4

Следует ли применять семантическую функциональную совместимость? Какой уровень семантической информации доступен от другой стороны?

Этап 5

Если ответ на этапе 4 «Да», то следует узнать параметры семантической совместимости и подключения (например, онтологию на основе ОпеМ2М). Затем следует разработать функцию добавления к отправляющей стороне для проверки связи с другой стороной

Этап 6

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

24

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

ПНСТ 930—2024

Этапы

Описание

Этап 7

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

Этап 8

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

25

ПНСТ 930—2024

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

Руководство по управлению жизненным циклом семантической совместимости ИВ

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

В таблице С.1 описан жизненный цикл спецификации функциональной совместимости, основанный на онтологии.

Таблица С.1 — Пример жизненного цикла спецификации функциональной совместимости

Жизненный цикл спецификации совместимости

Описание

Требования

Определение онтологий, которые необходимо создать или использовать

При необходимости следует ознакомиться с процессом создания и использования онтологий, см. [23], [24].

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

Следует определить возможность повторного использования или расширения существующих онтологий. Могут быть использованы каталоги, такие как LOV4loT [7].

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

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

Следует определить схему управления версиями онтологии

Спецификация

Совместная разработка онтологий

Следует настроить схему сотрудничества экспертов в предметной области и экспертов по онтологии для создания структуры и содержания онтологий. Руководство приведено в [20]. Рекомендации представлены в [30].

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

Следует проверить уровень модульности.

Следует установить процесс согласования между экспертами в предметной области и экспертами по онтологии

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

Следует перечислить понятия и отношения, которые должны поддерживаться онтологиями

Проверка спецификации совместимости с помощью онтологий

Следует перечислить зависимости, которые могут быть проверены.

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

Следует проверить ограничения в спецификации функциональной совместимости

Проверка соглашения

Ввод в эксплуатацию и развертывание семантической совместимости с интеграцией соответствующих онтологий

Следует обновить онтологии и спецификации при необходимости.

Следует провести оценку зрелости в экосистеме (например, в сообществе, которое будет использовать онтологию).

Интеграция в систему управления версиями онтологий

26

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

ПНСТ 930—2024

Жизненный цикл спецификации совместимости

Описание

Публикация

Обслуживание онтологии семантической

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

Публикация созданной или расширенной онтологии в существующих каталогах.

Следует обновить и усовершенствовать открытую онтологию.

Следует проверить обновленную онтологию

Вывод из эксплуатации онтологии семантической совместимости

Следует обновить управление версиями онтологий

С.2 Жизненный цикл системы ИВ, поддерживающий функциональную совместимость

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

Таблица С.2 — Пример жизненного цикла системы ИВ

Жизненный цикл системы ИВ

Действия по интеграции функциональной совместимости

Определение потребностей и требований заинтересованных сторон

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

Процесс определения системных требований

Интеграция требований спецификации функциональной совместимости в системные требования

Процесс определения архитектуры

Нет конкретной деятельности

Процесс проектирования

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

Процесс системного анализа

Нет конкретной деятельности

Процесс реализации

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

Процесс интеграции

Нет конкретной деятельности

Процесс проверки

Тестирование функциональной совместимости системы ИВ (внутрикорпоративное)

Процесс перехода

Тестирование функциональной совместимости системы ИВ (проверка третьей стороной, проверка подключения)

Процесс проверки развертывания

Проверка развертывания

Процесс эксплуатации

Нет конкретной деятельности

Процесс обслуживания

Интеграция модификаций спецификации функциональной совместимости

Процесс утилизации

Нет конкретной деятельности

27

ПНСТ 930—2024

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

Онтологическая спецификация типовой архитектуры ИВ

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

ГОСТР 57193 определяет общую типовую архитектуру ИВ с точки зрения характеристик системы и представлений архитектуры для ИВ. Настоящее приложение содержит онтологическую спецификацию типовой архитектуры. Онтологические спецификации созданы на языке веб-онтологий (OWL) и представлены в визуальной нотации для онтологий VOWL [31].

Онтология типовой архитектуры необходима в случае обмена системами ИВ информацией, которая включает ссылки на объекты архитектуры ИВ, например на этапах обнаружения датчиков и приложений. В онтологии используются стандартизированные понятия в связи с тем, что типовая архитектура стандартизирована. Это является значимым фактором, поскольку разные онтологии могут использовать понятия с одним и тем же именем. Например, в онтологии SSN [14] определено понятие «устройство». Онтология OWL-S [32] определяет понятие «служба». Если указанные онтологии используются одновременно с онтологией типовой архитектуры ИВ, то следует определить, имеют ли эти понятия то же значение, что и в онтологии типовой архитектуры ИВ.

D.2 Служба, сеть, устройство ИВ и шлюз ИВ

Служба — это абстрактное понятие. Служба реализуется одним или несколькими компонентами. Может быть несколько альтернативных реализаций одной и той же службы. Сущности взаимодействуют через оконечные точки в сети. Сеть соединяет оконечные точки. Служба предоставляет одну или несколько оконечных точек, с помощью которых она может быть вызвана. Оконечная точка имеет один или несколько сетевых интерфейсов. Удаленные службы могут быть доступны оконечным точкам через сетевые интерфейсы в коммуникационной сети. Оконечные точки могут существовать в одной или нескольких сетях. Данные, связанные со службами, устройствами ИВ и шлюзами ИВ, могут храниться в хранилище данных, используемом одной или несколькими сущностями. На рисунках D.1 и D.2 представлены сущности системы ИВ, связанные со службой, сетью, устройством ИВ и шлюзом ИВ.

----► -подкласс

Рисунок D.1 — Сущность ИВ

28

ПНСТ 930—2024

Рисунок D.2 — Служба, сеть, устройство ИВ и шлюз ИВТ

D.3 Пользователь ИВ

Пользователь ИВ может быть либо человеком (пользователь-человек), либо цифровым (цифровой пользователь). Цифровой пользователь включает в себя службы автоматизации, которые действуют от имени пользователя-человека, например при взаимодействии между компьютерами. Цифровой пользователь взаимодействует с одной или несколькими службами прямо или косвенно через оконечную точку службы. Пользователь-человек взаимодействует через одно или несколько приложений. На рисунке D.3 пользователь ИВ показан как суперкласс пользователя-человека и цифрового пользователя.

29

ПНСТ 930—2024

-----► - подкласс

Рисунок D.3 — Пользователь ИВ

D.4 Виртуальная сущность, физическая сущность и устройство ИВ

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

Рисунок D.4 — Виртуальный объект, физический объект и устройство ИВ

30

ПНСТ 930—2024

D.5 Типовая модель на основе доменов

Домены позволяют разработчику сосредоточиться на различных задачах, которые необходимо выполнить, разделяя задачи по логическому (иногда физическому) принципу. В основном, домены используются для группирования функций по областям ответственности, которые затем, как правило, развертываются в отдельных подсистемах. В типовой модели определены следующие домены: домен пользователей (User Domain, UD), домен эксплуатации и управления (Operations & Management Domain, OMD), домен приложений и служб (Application & Service Domain, ASD), домен доступа и обмена ресурсами (Resource Access & Interchange Domain, RAID), домен восприятия и контроля (Sensing & Controlling Domain, SCD) и домен физических сущностей (Physical Entity Domain, PED). Каждый домен не пересекается с другими доменами. Взаимосвязь между типовой моделью на основе сущностей и типовой моделью на основе доменов показана на рисунке D.5. В разных представлениях каждый домен включает различные сущности.

Пользователь

ИВ _

Включает

Домен

пользователей

Сеть

Взаимодействует с

заимодеиствует с

л

Взаимодействует через

Домен эксплуатации и ^управления

Подсистема4 эксплуатации и управления.

Взаимодействует с

Домен

приложении и

Взаимодействует с

Взаимодействует с

Включает

Подсистема приложений и служб

Шлюз ИВ

служб

Взаимоде йствует с

Домен восприятия и контроля

Включает

Включает

Устройство ИВ

-----*• — подкласс

Рисунок D.5 — Типовая модель на основе доменов

Домен доступа иЛ обмена ресурсами

Подсистема доступа

и обмена ресурсами

31

ПНСТ 930—2024

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

Онтологии, существующие в области ИВ

Е.1 Онтология семантической сенсорной сети (SSN W3C)

Консорциум W3C разработал онтологию SSN [14], которая обеспечивает высокоуровневую схему для описания датчиков и их наблюдений, процедур, изучаемых особенностей, используемых образцов, наблюдаемых свойств и исполнительных устройств. SSN следует горизонтальной и вертикальной модульной архитектуре путем использования легковесной автономной основной онтологии SOSA (Sensor, Observation, Sample и Actuator) для своих элементарных классов и свойств.

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

Онтология SSN связана с шаблоном «стимул—датчик—наблюдение» (stimulus-sensor-observation). Стимулами являются обнаруживаемые изменения в физическом мире. Датчики — физические объекты, которые выполняют наблюдения. Наблюдения действуют как связующее звено между входящими стимулами, датчиком и выходом датчика.

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

Е.2 Онтология loT-Lite

Онтология loT-Lite [33] позволяет представлять ресурсы, сущности и службы ИВ. Онтология loT-Lite, представляющая собой упрощенную версию онтологии SSN, может описывать ключевые понятия ИВ, обеспечивающие функциональную совместимость и обнаружение сенсорных данных на разнородных платформах ИВ.

Онтология loT-Lite описывает понятия ИВ в трех классах: объекты, система/ресурсы и службы. Устройства ИВ подразделяются на три класса, хотя не ограничиваются ими: сенсорные устройства, исполнительные устройства и устройства с метками. Онтология loT-Lite ориентирована на восприятие данных, хотя имеет высокоуровневую концепцию исполнения, которая допускает будущее расширение в этой области. Для описания служб используется покрытие, представляющее собой 20-пространство, охватываемое устройством ИВ [33].

Е.З Онтология Орел Connectivity Foundation (OCF)

Архитектура OCF (см. [34]) определяет клиент-серверную архитектуру согласно рисунку Е.1. Серверная часть архитектуры состоит из физических датчиков и исполнительных устройств. OCF построен на концепции RESTful, т. е. управляется с использованием небольшого набора общих операций: СОЗДАТЬ (CREATE), ИЗВЛЕЧЬ (RETRIEVE), ОБНОВИТЬ (UPDATE), УДАЛИТЬ (DELETE) и УВЕДОМИТЬ [CRUDN (NOTIFY CRUDN)].

32

Клиент

ПНСТ 930—2024

/ Роли OCF

Сервер

Уровень модели ресурсов OCF RESTful

Сеть

Конкретная реализация протокола данных/ сообщений

Устройство OCF

Реализация операций CRUDN, определяемая протоколом (например, СоАР, HTTP, ХМРР)

Например, GET/s/data

Запрос СОАР

Ответ СОАР

Ресурс

Отображение

Сущность (например, электрическая лампа)

Устройство OCF

Реализация сервера, определяемая протоколом

Абстракции OCF

Рисунок Е.1 — Архитектура OCF (см. [34])

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

Устройство 1

Рисунок Е.2 — Модель уровней связи [35]

Вертикальные домены описываются моделями ресурсов. Для моделей ресурсов используется язык разработки RESTful API OpenAPI 2.0. Моделирование ресурсов основано на концепциях архитектуры, в соответствии с которыми устройства OCF размещают ресурсы. Каждое устройство OCF имеет тип устройства (например, холодильник — oic.d.refrigerator). С каждым типом устройства связан минимальный обязательный набор ресурсов, которые должны быть реализованы данным типом устройства, при необходимости могут быть реализованы дополнительные ресурсы. Существуют следующие типы ресурсов:

33

ПНСТ 930—2024

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

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

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

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

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

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

Разделение моделирования ресурсов и структуры OCF также означает, что разработка моделей ресурсов отделена от архитектуры. Для разработки моделей данных ОРС предоставляет инструмент oneloTa (www.onelOTa. org) (см. рисунок Е.З). Инструмент oneloTa представляет собой интегрированную среду разработки (IDE), которая поддерживает разработку моделей данных и имеет интегрированный процесс принятия и публикации моделей данных.

Утвержденные модели данных загружаются на Github

Пользователи могут загружать модели или редактировать их и повторно отправлять на утверждение

Пользователи __ загружают

новые модели IВ

данных

Рецензенты выпускают утвержденную модель данных

oneloTa

Рецензенты одобряют или отклоняют предложения по модели данных

Отправители создают и отправляют предложение на утверждение

Рисунок Е.З — Среда разработки oneloTa [38]

Инструмент oneloTa также поддерживает производные модели. Производное моделирование — это механизм перевода между моделями OCF и другими моделями. Примером производной модели является преобразование между моделями OCF и Zigbee*

На рисунке Е.4 представлена онтология OCF. Все серверы и клиенты OCF являются экземплярами OCFDevice. Онтология дополнительно описывает как простые, так и сложные ресурсы, включающие экземпляры Collection Interface и OCFLink. Операции CRUDN представлены в определении метода, которое предоставляется OCFResource и определяется OCFInterfaceType. Представление устройств обеспечивается значениями OCFProperty.

На рисунке Е.4 используются следующие обозначения:

- С: класс UML, представляющий объекты, реализуемые ресурсами;

- Е: перечисление UML, представляющее набор значений, которые может принимать тип или метод.

* Zigbee — торговая марка продукта, поставляемого компанией Zigbee Alliance. Данная информация дана для удобства пользователей настоящего стандарта и не является рекомендацией.

34

ПНСТ 930—2024

Рисунок Е.4 — Онтология OCF

35

ПНСТ 930—2024

Е.4 Базовая онтология умных приложений SAREF

Базовая онтология умных приложений SAREF (см. [36]), разработанная в рамках технического комитета ETSI SmartM2M ТС, предназначена для обеспечения функциональной совместимости между решениями от разных поставщиков и между различными секторами деятельности ИВ, тем самым способствуя развитию мирового цифрового рынка.

SAREF — базовая онтология для умных приложений, содержащая повторяющиеся понятия, используемые в нескольких областях. Для обеспечения работы с дополнительными понятиями и предоставления различным доменам необходимой онтологии, которая отражает конкретные потребности этого домена, созданы расширения SAREF. На рисунке Е.5 SAREF показана как основная модель, которую следует использовать в качестве основы для создания расширений в различных доменах. Расширения SAREF созданы для энергетики, окружающей среды, строительства, сельского хозяйства, промышленности и производства, умного города, автомобилестроения, электронного здравоохранения, носимых устройств и водных ресурсов.

Онтологии SAREF размещены на общедоступном портале онтологий SAREF [37], который позволяет пользователям просматривать различные версии онтологии SAREF и ее расширений, а также взаимодействовать и вносить вклад в непрерывную разработку онтологий.

Рисунок Е.5 — SAREF и расширения (см. [36])

SAREF фокусируется на понятии устройства и на производимых им измерениях. Эти измерения могут быть связаны с различными свойствами объектов интереса. Онтология предоставляет список основных функций, которые могут быть рассмотрены как строительные блоки для комбинации, чтобы иметь более сложные функции в одном устройстве. Устройство при подключении к сети предлагает службы, предоставляющую одну или несколько функций в сети, делая их доступными для обнаружения, регистрации и дистанционного управления другими устройствами в сети. На рисунке Е.6 представлен обзор основных классов SAREF и их взаимосвязей.

36

ПНСТ 930—2024

Рисунок Е.6 — Обзор онтологии SAREF (см. [36])

Е.5 Базовая онтология опеМ2М

Онтологии и их OWL-представления используются в опеМ2М для обеспечения синтаксической и семантической совместимости системы опеМ2М с внешними системами. Предполагается, что внешние системы должны описываться онтологиями. Единственная онтология, специфицируемая опеМ2М, — это базовая онтология опеМ2М [38]. Базовая онтология опеМ2М является минимальной (т. е. предписывающей наименьшее количество соглашений) и необходимой для того, чтобы другие онтологии могли быть отображены в опеМ2М.

Синтаксическая совместимость позволяет взаимодействовать с устройствами, отличными от опеМ2М, например в локальных сетях. В этом случае онтология, представленная в виде файла OWL и определяющая определенные для локальной сети типы параметров связи (названия операций, входные/выходные параметры, их типы и структуры и т. д.), используется для настройки сущности-посредника взаимодействия в решении опеМ2М.

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

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

Е.6 Язык сенсорной модели SensorML

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

Е.7 Онтология 1оТ-О

1оТ-О [40] представляет собой модульную основную онтологию ИВ, предоставляющую словарь для описания подключенных устройств и их связи с окружающей средой. loT-О может быть использована для семантического описания устройств и данных таким образом, чтобы предоставлять системам информацию об их среде, эволюции и изменениях, которые могут быть внесены. Такое описание позволяет умным агентам преобразовывать свою среду с помощью подключенных исполнительных устройств в соответствии с восприятием через подключенные датчики. loT-О состоит из нескольких модулей.

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

37

ПНСТ 930—2024

- модуль «Восприятие» (sensing) описывает входные данные. Основные классы происходят из онтологии SSN: ssn:Sensor и ssn:Observation. ssn:Device и его характеристики (ssn:OperatingRange, ssn:Deployment и т. д.) предоставляют общее описание устройства;

- модуль «Действие» (acting) описывает, как система может взаимодействовать с физическим миром. Его основные классы взяты из онтологии SAN: san:Actuator и san:Actuation. Модуль повторно использует классы SSN, не относящиеся к распознаванию, например ssn:Device;

- модуль «Жизненный цикл» (live cycle) моделирует диаграмму состояний для определения жизненных циклов системы и использования устройств. Его основными классами являются lifecycle:State и lifecycle:Transition;

- модуль «Службы» (service) представляет собой интерфейсы веб-сервисов. Его основные классы взяты из MSM: msm:Service и msm:Operation. Службы производят и потребляют msm:Messages, а службы RESTful могут быть описаны с помощью hRest;

- модуль «Энергетика» (energy) определяется PowerOnt. Он предоставляет класс poweront:PowerConsumment и набор свойств для выражения профилей энергопотребления для устройств;

- являясь основной предметной онтологией, loT-О предназначена для расширения в отношении конкретных прикладных потребностей и реальных устройств и служб. Конструкция онтологии делает loT-О независимой от приложения. 1оТ-О — это название и онтологии, и верхнего модуля. loT-О проводит концептуализацию домена ИВ, независимого от приложения, предоставляя классы и отношения для связи базовых модулей. Поскольку многие понятия уже определены в модулях, основная онтология loT-О ограничена 14 классами, 18 свойствами объектов и 4 свойствами данных. Ключевой класс loT-О — iot-o;loT_Thing, который может быть либо ssn:Device, либо iot-o:SoftwareAgent. Энергопотребление ssn:Devices связано с lifecycle:State и poweront:PowerConsumment. iot-o:loT_Thing является поставщиком msm;Service, a msm:Operation может иметь iot-o:ImpactOnProperty в ssn:Property, связывая абстрактные службы с физическим миром через устройства.

Е.8 Подход к унификации онтологий ИВ

Онтология FIESTA-loT [41], [42] представляет собой сеть онтологий ИВ, которая обеспечивает единую семантическую модель. Онтология FIESTA-loT представляет собой слияние понятий из различных онтологий, таких как loT-Lite, таксономия M3-lite, W3C SSN:

- онтология М3 (межмашинное измерение) [43] была усовершенствована в M3-lite (http://purl.org/iot/vocab/ m3-lite#) и интегрирована с другими онтологиями ИВ (например, W3C SSN). Онтология М3 описывает более чем 30 датчиков, измерений, единиц измерения и около 10 областей. Онтология М3 ориентирована на понятие ssn:ObservationValue из онтологии W3C SSN, которое описывает датчики и наблюдения, а также связанные понятия. Таксономия M3-lite — это облегченная версия онтологии М3. МЗ-lite содержит таксономию для различных физических явлений и явлений окружающей среды, единиц измерения, различных типов датчиков и различных типов областей интересов;

- loT-Lite (см. Е.2);

- SSN W3C (см. Е.1).

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

МЗ-lite был разработан для пяти испытательных стендов. Более подробная информация об указанных испытательных стендах, а также об участниках, присоединившихся к платформе FIESTA-loT, доступна по адресу: http:// fiesta-iot.eu/index.php/fiesta-testbeds.

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

38

ПНСТ 930—2024

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

[1] Martin Bauer et al. Towards semantic interoperability standards based on ontologies. AIOTI white paper. June 2019

[2] ETSI TS 103 264 V2.1.1, SmartM2M; Smart appliances; Reference ontology and OneM2M mapping. 2017. https://www.etsi.org/deliver/etsi_ts/103200_103299/103264/02.01.01_60/ts_103264v02 0101p.pdf

[3] Matthias Weise, Maria Poveda-Villalon, Mari Carmen Suarez-Figueroa, Raul Garcia- Castro, Jerome Euzenat, Luz Priego, Bruno Fies, Andrea Cavallaro, Jan Peters-Anders, Kleopatra Tsagkari. Ontologies and datasets for energy management system interoperability (2014). Research gate

[4] ETSI TS 103 410-4 V1.1.1, SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain. 2019. https://www.etsi.Org/deliver/etsi_ts/103400_103499/10341004/01.01,01_60/ts_103410 04v010101p.pdf

[5] ETSI TS 103 410-5 V1.1.1, SmartM2M; Extension to SAREF; Part 5: Industry and Manufacturing Domains. 2019. https://www.etsi.Org/deliver/etsi_ts/103400_103499/10341005/01.01.01_60/ts_103410 05v010101p.pdf

[6] ETSI TS 103 410-6 V1.1.1, SmartM2M; Extension to SAREF; Part 6: Smart Agriculture and Food Chain Domain. 2019.

https://www.etsi.Org/deliver/etsi_ts/103400_103499/10341006/01.01.01 _60/ts_103410 06v010101p.pdf

/77 Linked Open Vocabularies for Internet of Things (LOV4loT). http://lov4iot.appspot.com/

[8] RDF Primer. W3C Recommendation. https://www.w3.org/TR/rdf-primer/

[9] RDF Schema. W3C Recommendation. https://www.w3.org/TR/rdf-schema/

[10] Web Ontology Language (OWL). W3C. https://www.w3.org/OWL/

[11] SPARQL 1.1 Query Language. W3C Recommendation 21 March 2013.

https://www.w3.org/TR/sparql11 -query/

[12] Semantic Web — XML2000, slide 10. W3C. https://www.w3.org/2000/Talks/1206-xml2ktbl/slide10-0.html

[13] JSON-LD 1.1. A JSON-based Serialization for Linked Data. W3C Recommendation 16 July 2020. https://www. w3.org/TR/json-ld/

[14] Semantic Sensor Network Ontology. W3C Recommendation 19 October 2017. https://www.w3.org/TR/vocab-ssn/

[15] Review of Sensor and Observations Ontologies. W3C.

https://www.w3.org/2005/lncubator/ssn/wiki/Review_of_Sensor_and_Observations_ Ontologies

[16] Linked Open Vocabularies (LOV). https://lov.linkeddata.es/dataset/lov/

[17] Friend of a Friend (FOAF): an experimental linked information system, http://www.foaf-project.org/

[18] Amit P. Sheth. Changing Focus on Interoperability in Information Systems: in System, Syntax, Structure to Semantics, Interoperating Geographic Information Systems, M F Goodchild, M J Egenhofer, R Fegeas and C A Kottman (eds). Kluwer, pp 5-29, 1999

[19] Paul Murdock et al., Semantic Interoperability for the Web of Things, ResearchGate, August 2016. https://www.researchgate.net/publication/307122744_Semantic_lnteroperability_for_ the_Web_of_Things

[20] Martin Bauer et al. Semantic loT Solutions: A Developer Perspective. June 2019

[21] Internet of Things loT Semantic Interoperability: Research Challenges, Best Practices, Recommendations and Next Steps. European Research Cluster on the Internet of Things, 2015...

http://www.internet-of-thingsresearch. eu/pdf/IERC_Position_Paper_loT_Semantic_lnteroperability_Final.pdf

[22] ISO/IEC TR 22417:2017, Information technology — Internet of Things (loT) — loT use cases

[23] Natalya F. Noy, Deborah McGuinness. Ontology development 101: A guide to creating your first ontology,

https://protege.stanford.edu/publications/ontology_development/ontology101.pdf

[24] WebProtege user guide. https://protegewiki.stanford.edu/wiki/WebProtegeUsersGuide

39

ПНСТ 930—2024

[25] Jena Framework to build semantic web and linked data applications, https://jena.apache.org/

[26] Jena inference support, https://jena.apache.org/documentation/inference/

[27] 3rd tutorial on «semantic web meets internet of things and web of things», 2017...

http://semantic-web-ofthings.appspot.com/tutorial_ISWC2017/05_HandsOnSession_%20IC2017Tutorial_Amelie_ Gyrard_V1.pdf

[28] Mari Carmen Suarez, Asuncion Gomez-Perez, Mariano Fernandez-Lopez, The Neon Methodology for Ontology Engineering, in Ontology Engineering in a Networked World, 2012, Springer Com

[29] FAQ for Ontologies: Exploring the state of the art with interactive mind maps.

http://perfectsemanticweb.appspot.com/?p=ontology_sota#div_ontology_methodology_ mindmap

[30] Amelie Gyrard, Martin Serrano, Ghislain Atemezing. Semantic Web Methodologies, Best Practices and Ontology Engineering Applied to Internet of Things. IEEE World Forum on Internet of Things (WF-loT), Milan, Italy, December 14-16, 2015. https://test.insightcentre.org/sites/default/files/publications/paperwfiot2015_ bestpracticessemanticwebiot.pdf

[31] VOWL: Visual Notation for OWL Ontologies, http://purl.org/vowl/spec/

[32] OWL-S: Semantic Markup for Web Services. W3C Member Submission 22 November 2004. https://www.w3.org/ Submission/OWL-S/

[33] loT-Lite Ontology, W3C Member Submission 26 November 2015, https://www.w3.org/Submission/2015/SUBM-iot-lite-20151126

[34] ISO/IEC 30118-1: Information technology — Open Connectivity Foundation (OCF) Specification — Part 1: Core specification

[35] oneloTa User Guide. http://openconnectivity.org/oneiota/Onelota_User_Guide.pdf

[36] ETSI TS 103 264 V3.1.1, SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping. 2020... https://www.etsi.org/deliver/etsi_ts/103200_103299/103264/03.01.01_60/ts_103264v03 0101p.pdf

[37] SAREF ontology portal, https://saref.etsi.org/

[38] oneM2M Technical Specifications, TS-0012 oneM2M Base Ontology, version 2.2.2 Release 2, 2018-03-12, http:// www.onem2m.org/technical/published-drafts

[39] OGC SensorML: Model and XML Encoding Standard, http://docs.ogc.org/is/12- 000r2/12-000r2.html

[40] Seydoux, Khalil Drira, Nathalie Hernandez, and Thierry Monteil, loT-O, a Core-Domain loT Ontology to Represent Connected Devices Networks, 20th International Conference, EKAW 2016, Bologna, Italy, November 19-23, 2016... https://www.researchgate.net/publication/309695394_loT-O_a_Core-

Domain_loT_Ontology_to_Represent_Connected_Devices_Networks

[41] FIESTA-loT: Federated Interoperable Semantic loT/Cloud Testbeds and Applications. H2020 EU project, 2015-2018. https://cordis.europa.eu/project/id/643943

[42] Agarwal et al. Unified loT Ontology to Enable Interoperability and Federation of Testbeds. Third IEEE World Forum on Internet of Things (WF-loT), 2016

[43] Amelie Gyrard. Designing Cross-Domain Semantic Web of Things Applications. Ph.D.

Thesis, Telecom ParisTech, 2015.

http://www.eurecom.fr/fr/publication/4553/download/cm-publi-4553.pdf

40

ПНСТ 930—2024

УДК 004.738:006.354

ОКС 35.110

Ключевые слова: информационные технологии, интернет вещей, функциональная совместимость, семантическая функциональная совместимость, онтология

41

Редактор Л.В. Каретникова

Технический редактор В.Н. Прусакова

Корректор О.В. Лазарева

Компьютерная верстка Е.А. Кондрашовой

Сдано в набор 02.09.2024. Подписано в печать 10.09.2024. Формат 60x847s. Гарнитура Ариал.

Усл. печ. л. 5,58. Уч.-изд. л. 3,96.

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

Создано в единичном исполнении в ФГБУ «Институт стандартизации» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.