"ПНСТ 930-2024 (ИСО/МЭК 21823-3:2021). Предварительный национальный стандарт Российской Федерации. Информационные технологии. Интернет вещей. Совместимость систем интернета вещей. Часть 3. Семантическая совместимость"
(утв. и введен в действие Приказом Росстандарта от 29.08.2024 N 45-пнст)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CoAP - протокол ограниченного приложения (Constrained Application Protocol);

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

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

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

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

LOV4IoT - связанные открытые словари для интернета вещей (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);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- отображения;

- отношения онтологий

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

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

- отображения;

- отношения онтологий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

- подкласс

- подкласс

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

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

Домены позволяют разработчику сосредоточиться на различных задачах, которые необходимо выполнить, разделяя задачи по логическому (иногда физическому) принципу. В основном, домены используются для группирования функций по областям ответственности, которые затем, как правило, развертываются в отдельных подсистемах. В типовой модели определены следующие домены: домен пользователей (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. В разных представлениях каждый домен включает различные сущности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разделение моделирования ресурсов и структуры OCF также означает, что разработка моделей ресурсов отделена от архитектуры. Для разработки моделей данных OPC предоставляет инструмент oneIoTa (www.oneIOTa.org) (см. рисунок E.3). Инструмент oneIoTa представляет собой интегрированную среду разработки (IDE), которая поддерживает разработку моделей данных и имеет интегрированный процесс принятия и публикации моделей данных.

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

--------------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- модуль "Восприятие" (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 и набор свойств для выражения профилей энергопотребления для устройств;

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

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

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

- IoT-Lite (см. E.2);

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

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

M3-lite был разработан для пяти испытательных стендов. Более подробная информация об указанных испытательных стендах, а также об участниках, присоединившихся к платформе FIESTA-IoT, доступна по адресу: /template/go.php?url=https://fiesta-iot.eu/index.php/fiesta-testbeds.

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