Предварительный национальный стандарт ПНСТ 433-2020 "Информационные технологии. Интернет вещей. Требования к платформе обмена данными для различных служб интернета вещей" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 11 августа 2020 г. N 42-пнст) (документ не действует)

Предварительный национальный стандарт ПНСТ 433-2020
"Информационные технологии. Интернет вещей. Требования к платформе обмена данными для различных служб интернета вещей"
(утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 11 августа 2020 г. N 42-пнст)

Information technology. Internet of things. Requirements to data exchange platform for various internet of things services

ОКС 35.110

Срок действия - с 1 января 2021 г.
до 1 января 2024 г.

Предисловие

1 Разработан Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Акционерным обществом "Российская венчурная компания" (АО "РВК")

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

3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 11 августа 2020 г. N 42-пнст

Введение

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

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

б) службы ИВ требуют различных эксплуатационных характеристик оконечных точек в сетях связи;

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

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

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

В настоящем стандарте приведены требования и рекомендации по приведенным выше перечислениям.

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

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

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

Настоящий стандарт содержит рекомендации по внедрению указанных компонентов.

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

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

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

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

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

В настоящем стандарте применены следующие термины с соответствующими определениями (см. также [1]):

3.1 механизм связи (communication mechanism): Механизм, определяющий последовательности и форматы сообщений, которые используются сущностями с интерфейсами связи.

3.2 платформа обмена данными ИВ (IoT data exchange platform): Платформа, включающая в себя функциональные блоки, которые обеспечивают абстракцию малых блоков данных ИВ.

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

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

3.4 функциональность сети (network functionality): Функциональность, предоставляемая функциональными блоками путем обработки информации для передачи в сущность с интерфейсами связи.

3.5 узловая точка (nodal point): Точка анализа информации из блоков передачи данных в соответствии с протоколами связи.

3.6 сокет (socket): Интерфейс между прикладным уровнем и транспортным уровнем, идентифицируемый номерами портов.

4 Сокращения

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

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

ASD - домен приложений и служб (Application & Service Domain);

ASIC - интегральная схема специального назначения (Application-Specific Integrated Circuit);

САС - контроль коммуникационного доступа (Communication Access Control);

CCN - контентно-ориентированная сеть (Information Centric Network);

DEP - платформа обмена данными (Data Exchange Platform);

DNS - служба доменных имен (Domain Name Service);

ICN - информационно-ориентированная сеть (Information Centric Network);

IP - Интернет-протокол (Internet Protocol);

MQTT - протокол организации очередей доставки телеметрических сообщений (Message Queuing Telemetry Transport);

OBD - домен объектов (Object Domain);

OMD - домен эксплуатации и управления (Operation and Management Domain);

OSI - взаимодействие открытых систем (Open Systems Interconnection);

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

RFID - радиочастотная идентификация (Radio-Frequency Identification);

RID - домен обмена ресурсами (Resource Interchange Domain);

SCD - домен восприятия и контроля (Sensing and Controlling Domain);

TCP - протокол управления передачей (Transmission Control Protocol);

UD - домен пользователей (User Domain);

UDP - протокол пользовательских датаграмм (User Datagram Protocol).

5 Краткие сведения о службах ИВ

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

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

Сценарии использования ИВ, использованные при разработке настоящего стандарта, кратко изложены в приложении А.

6 Конфигурации сети для служб ИВ

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

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

Рисунок 1 - Сети в типовой архитектуре ИВ

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

Рисунок 2 - Конфигурации сети для различных служб

7 Платформа обмена данными в типовой архитектуре ИВ

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

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

DEP распространяется на сущности ИВ и работает как платформа для объединения распределенных частей.

7.2 Конфигурации сети для DEP

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

С помощью конфигурации сети для DEP пять конфигураций сети, указанных на рисунке 2, объединяются в три конфигурации (рисунок 3). Конфигурации 1-5 переопределены как конфигурации X, Y и Z.

Рисунок 3 - Конфигурации сети для DEP

7.3 DEP в типовой архитектуре ИВ

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

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

DEP интернета вещей должна обеспечивать следующую функциональность:

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

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

- DEP должна управлять проверкой путей связи и устройств ИВ.

Рисунок 4 - Функции DEP в типовых моделях ИВ

На рисунке 4 подсистема доступа и обмена ресурсами установлена как узловая точка для каждой сети, показанной на рисунке 3.

7.4 Функционирование DEP в системе ИВ

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

Рисунок 5 - Сценарии использования DEP и взаимосвязь между службами ИВ и другими службами

Функционирование DEP в каждом сценарии использования включает в себя следующие сценарии:

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

Рисунок 6 - Функционирование DEP в сценарии использования А

- сценарий использования Б: DEP выполняет роль узловой точки. Типы сетей включают в себя сети ближнего действия, сети доступа, сети служб и пользовательские сети. DEP должна применяться во всех типах сетей, кроме сетей ближнего действия. Как показано на рисунке 7, приложения ИВ должны предоставляться между сетевыми интерфейсами через DEP. Другие приложения должны предоставляться между сетевыми интерфейсами без DEP. DEP должна изолировать каналы связи для приложений ИВ от других приложений для обеспечения требуемого качества обслуживания;

Рисунок 7 - Функционирование DEP в сценарии использования Б

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

Рисунок 8 - Функционирование DEP в сценарии использования В

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

Рисунок 9 - Функционирование DEP в сценарии использования Г

8 Требования к DEP системы ИВ

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

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

8.2 Требования к функциональным блокам

8.2.1 Функциональные блоки

DEP состоит из функциональных блоков в соответствии с рисунком 10.

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

Рисунок 10 - Функциональные блоки DEP

Таблица 1 - Взаимосвязи между функциональными блоками и сценариями использования DEP

Блок	Сценарий использования А	Сценарий использования Б	Сценарий использования В	Сценарий использования Г
Контроль коммуникационного доступа	X	X	X	X
Контроль данных	-	X	X	-
Трансляция данных	-	-	-	X
Контроль ИВ	X	X	X	X
Управление ИВ	X	X	X	X
Адаптация	X	X	X	X
Примечание - "X" - есть взаимосвязь, "-" - взаимосвязь отсутствует.

8.2.2 Контроль коммуникационного доступа

САС должен обеспечивать обработку протокола для приложений ИВ, как показано на рисунке 11.

Рисунок 11 - Взаимодействия между блоками САС

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

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

DEP относится к прикладному уровню, как показано на рисунке 12. Следовательно, САС должен быть адаптирован между приложениями ИВ и нижними уровнями, как показано на рисунке 13. САС должен абстрагировать протоколы нижнего уровня. В приложениях ИВ для передачи данных могут быть развернуты различные сети. САС должен обеспечить независимость этих сетей для приложений ИВ, при этом САС не должен исследовать или изменять содержимое в блоках данных приложений ИВ. В настоящем стандарте механизмы защиты не рассматриваются.

Рисунок 12 - Структура уровней платформы обмена

Рисунок 13 - Независимость между САС и низкоуровневыми протоколами

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

Рисунок 14 - Архитектура сосуществования приложений ИВ и других приложений

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

8.2.3 Контроль данных

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

8.2.4 Трансляция данных

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

8.2.5 Контроль ИВ

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

8.2.6 Управление ИВ

Управление ИВ должно проводить мониторинг сбоев DEP и маршрутов связи между DEP и другой DEP.

8.2.7 Адаптация

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

8.3 Протоколы связи

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

Рисунок 15 - Передача данных между протоколами связи в DEP

8.4 Схема служб

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

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

Рисунок 16 - Связи между пользователями ИВ и службами ИВ с использованием DEP

Рисунок 17 - Связи между пользователями ИВ и службами ИВ без использования DEP

9 Операции платформы обмена данными ИВ

Операции DEP показаны на рисунке 18 и определены далее.

Рисунок 18 - Операции контроля информации с использованием DEP

Операции DEP:

1) предустановленные маршруты передачи. При подписке пользователей на приложение ИВ управление ИВ устанавливает маршруты передачи в DEP;

2) запрос на сбор данных. При сборе пользователями ИВ данных от устройств ИВ (например, датчиков) передается сообщение запроса в DEP в сетях, использующих предустановленные маршруты. Для данной операции не требуется DNS, хотя он является обязательным для Интернета. В случае нескольких предустановленных маршрутов DEP разрешает выбор маршрута. IP и связанные с ним протоколы изолированы от данной операции;

3) передача данных. Устройство ИВ передает данные в DEP в сетях, описанных в 2). DEP может кэшировать данные. Впоследствии, когда пользователь ИВ запрашивает передачу данных, DEP передает данные из кэша вместо устройства ИВ. К механизмам передачи данных применяются технологии ICN, которые описаны в приложении Б;

4) схемы доступа к данным. В операциях 2) и 3) применяют две схемы:

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

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

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

[1]	ИСО/МЭК 20924:2018, Информационные технологии. Интернет вещей. Словарь (Information technology - Internet of Things (IoT) - Vocabulary)
[2]	Bengt Ahlgren, Christian Dannewitz, Claudio Imbrenda, Dirk Kutscher and Ohlman. A Survey of Information-Centric Networking, IEEE Communications Magazine, July 2012