agosty.ru35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ35.110. Организация сети

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

Обозначение:
ПНСТ 433-2020
Наименование:
Информационные технологии. Интернет вещей. Требования к платформе обмена данными для различных служб интернета вещей
Статус:
Действует
Дата введения:
01.01.2021
Дата отмены:
Заменен на:
-
Код ОКС:
35.110

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

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

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

пнет

433—

2020



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

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

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

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

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

мсхжвя

2ОП

Предисловие

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

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

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

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

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мве до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва. Инновационный центр Сколково, ул. Нобеля, д. 1. e-mail: [email protected] и/или в Федеральное агентство по техническому регулированию и метрологии: 123112 Москва. Пресненская набережная, д.10, стр. 2.

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

© Стзндартинформ, оформление. 2020

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

Содержание

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

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

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

  • 4 Сокращения

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

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

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

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

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

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

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

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

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

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

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

  • 8.4 Схема служб

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

Приложение А (справочное) Примеры систем на основе платформы обмена данными

Приложение Б (справочное) Протоколы связи для ICN

Приложение В (справочное) Рекомендации по реализации DEP

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

Введение

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

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

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

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

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

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

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

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

Информационные технологии ИНТЕРНЕТ ВЕЩЕЙ

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

Information technology. Internet of things.

Requirements to data exchange platform for various internet of things services

Срок действия —c 2021—01—01 до 2024—01—01

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

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

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

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

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

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

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

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

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

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

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

  • 3.2 платформа обмена данными ИВ (loT 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);

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

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

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

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

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

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

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

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

X Y Z

Легальные службы

и Глобальные службы

И Пользователи ИВ 11

Z \ / \ / | Сеть ближнего ■ | действия \ / VZ

/ ПользоваД / Сеть \

I тельекзя I 1 служб/ 1

\ сеть 1 \ доступа 1

Шлюз ИВ Шлюз ИВ Г

/ Бессон- \ / Веской- \

1 такгкая 1 I тахтная ]

VV V/

1 Польэоы- Сеть служб/1

1 тельсхая ______ 1

сеть доступа

И Устройства ИВ 1|

1 III 2 3 I

4 5

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

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

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

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

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

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

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

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

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

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

Пользователи ИВ

DEP



Сеть


Сеть


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


Домен приложений и служб


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


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


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

Подсистема

1

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

DEP

J


Сеть

Сеть

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

[ Шлюз ИВ

DEP |

________________й_____

1

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

DEP

(Доменфизических f сущностей

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


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

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

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

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

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

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

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

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

Сет» доступа, сеть служб, потжооаятвльскао еет»

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

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

С

>Е₽

7—

Служив ИЬ

Шпк>3 ИВ

1 Другие службы !

7“

X

/ i

(Пр.

*

Сетевой «терфейс окскыалывя сет»)

Сетевой интерфейс (сете доступа

>

Рисунок 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 действует как точка взаимодействия.

DEP


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


со s


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


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



Адаптация

Пользователи ИВ. шлюз ИВ. устройства ИВ или подсистема доступа и обмена ресурсами

Сетевые интерфейсы

Рисужж 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 должен транслировать в оконечных точках исходные данные от устройств ИВ или пользователей ИВ в блоки данных и наоборот. 8 точках взаимодействия САС должен передать блохи данных другим САС. независимо от протоколов нижнего уровня и среды передачи.

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

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

Базовая модель OSI

Интернет

Прикладной уровень DEP (контроль коммуникационного доступа)

Прикладной уровень DEP (контроль коммуникационного доступа)

Уровень представления

Сеансовый уровень

Транспортный уровень

Транспортный уровень (TCP. UDP)

Сетевой уровень

Сетевой уровень (IP)

Канальный уровень

Уровень данных

Физический уровень

Физический уровень

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

Службы ИВ

Протоколы прикладного уровня

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

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

I Ранее

I разработанные

Приложения ИВ

Протоколы ранее I разработанных __приложений___^

Сосуществование


I приложения I

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


DEP {например. ICN|


Инфраструктура Интернета

Рисунок 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 и определены далее.

- маршруты предустановленные функциями управления;

- лоток данных для приложения ИВ 2

Рисунок 1В — Операции контроля информации с использованием 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 Система отслеживания сельскохозяйственной продукции: участники и обмен информацией

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

Рисунок А.1 — Система отслеживания сельскохозяйственной продукции

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

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

А.2 Система мониторинга оконечных точек ИВ

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

Рисунок А.2 — Система мониторинга оконечных точек ИВ

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

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

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

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

БД В настоящем приложении представлены технологии информационно-ориентированной сети (ICN) в качестве примера платформы обмена данными.

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

  • • сетевая архитектура, ориентированная на данные (DONA):

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

  • • парадигма издатель-подписчик интернет-маршрутизации (PSIRP):

  • • сеть информации (Nellnf).

PSIPR — это асинхронная архитектура с использованием публикации и подписки. Протокол MQTT относится к данному типу. Другие типы являются синхронной архитектурой с использованием запроса данных по требованию и ответа, которые являются парными. Свойства типов представлены в таблице Б.1 (см. также [2]).

Таблица БД—Свойства типов технологий ICN

Свойство

DONA

CCN

PSIRP

Nellnf

Пространство имен

Плоское со структурой

Иерархическое

Плоское со структурой

Плоское со структурой

Целостность именованных данных

Подпись. PKI-независимое

Подпись, внешний доверенный источник

Подпись. РККнезаэисимое

Подпись или хэш-контент. PKI-независимое

Удобочитаемые имена

Нет

Возможны

Нет

Нет

Абстрактная модель информации

Нет

Нет

Нет

Да

Уровень детализации

Объекты

Пакеты

Объекты

Объекты

Агрегация маршрута

Подписка/явная

Подписка

Область/явная

Подписка

Маршрутизация запросов

На основе имен

На основе имен

Служба разрешения имен

Гибридная схема разрешения имен и на основе имен

Маршрутизация

Обратный путь запроса или прямое соединение 1Р

Обратный путь запроса на основе состояния маршрутизатора

Маршрутизация по источнику с фильтром Блума

Обратный путь запроса или прямое соединение IP

API

Синхронное получение

Синхронное получение

Публикация/ подписка

Синхронное получение

Протокол передачи данных

Большинство, включая IP

IP/PSIRP

Большинство, включая IP

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


Рекомендации по реализации DEP


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

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

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

• абстракция нижнего уровня в ОЕР:

- внутренние связи в компоненте DEP.


Службы


Прикладное прогрзммюе обеспечение


DEP


Промежуточное программное обеспечение


Транспортный уровень Сетевой уровень


Базовое программное обеспечение (ОС)


Канальный уровень


Драйвер устройства


Физический уровень


Специализированное устройство

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


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

В.2 Абстракция нижнего уровня в DEP

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

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

DEP

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

Протокол доступа


Протокол доступа


Протокол доступа


Интерфейс сокета

Порт 1 Порт 2 Порт 3

Транспортный уровень

Рисунок В.З — Реализация поддержки нескольких протоколов доступа в DEP

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



Рисунок В.4 — Реализация поддержки нескольких интерфейсов сокетов в DEP

При работе на канальном или физическом уровне DEP должен быть подключен к уровню через функцию адаптации. Функция адаптации объединяет различные интерфейсы на канальном или физическом уровне с интерфейсом сокета (см. рисунок В.5).

Рисунок В.5 — Реализация поддержки нескольких интерфейсов сокетов a DEP с функцией адаптации

В.З Внутренние соединения е DEP

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

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

  • [1] ИСО/МЭК 20924:2018. Информационные технологии. Интернет вещей. Словарь (Information technology — Internet of Things (loT) — Vocabulary)

  • [2] Bengt Ahlgren. Christian Dannewrtz. Claudio Imbrenda. Dirk Kutscher and Borja Ohlman. A Survey of Information-Centric Networking. IEEE Communications Magazine. Jufy 2012

УДК 004.738:006.354

ОКС 35.110


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

S3 9—2020/95

Редактор Н.В. Таланова Технический редактор И.Е. Черепкова Корректор ЕЛ- Дупьнева Компьютерная верстка И.А. Налеокиной

Сдано в набор 12.08.2020. Подписано е печать 04.09.2020. Формат 60*84’/^. Гарнитура Ариал. Усл. печ. л. 2.79. Уч.-изд. л. 2.37.

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

Создано в единичном исполнении во ФГУП «СТАНДАРТУ! НФОРМ» . 117418 Москва. Нахимовский пр-т, д. 31. к. 2. [email protected]