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

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

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

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

СЕТИ СЕНСОРНЫЕ

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

(1SO/IEC 30128:2014, MOD)

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

Москва Стаида ртмнформ 2020

Предисловие

• 1 ПОДГОТОВЛЕН Акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (АО «ВНИИС») и Акционерным обществом «Российская венчурная компания» (АО «РВК») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

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

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

• 4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 30128:2014 «Информационные технологии. Сенсорные сети. Сетевой интерфейс прикладного программирования датчика» (ISO/IEC 30128:2014 «Information technology — Sensor networks — Generic Sensor Network Application Interface», MOD) путем:

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

исключения структурного элемента.

Внесение указанных технических отклонений направлено на учет потребностей национальной экономики Российской Федерации.

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в дополнительном приложении ДА.

Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта приведено в дополнительном приложении ДБ

• 5 Некоторые элементы настоящего стандарта могут быть объектами патентных прав. Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) не несут ответственности за установление подлинности каких-либо или всех таких патентных прав

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

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 121205 Москва. Инновационный центр Сколково, ул. Нобеля, д. 1. e-mail: info@tc194.ru и/или в Федеральное агентство по техническому регулированию и метрологии: 109074 Москва. Китайгородский проезд, д. 7. стр. 1.

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

© ISO, 2014 — Все права сохраняются

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

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

Содержание

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

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

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

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

• 5 Обзор приложений сенсорных сетей

• 5.1 Модель связи

• 5.2 Операции клиента сенсорной сети

• 6 Возможности сенсорной сети

• 7 Защищенность

• 8 Модель сенсорных данных и метаданных

• 9 Спецификация общего интерфейса приложения универсальной сенсорной сети

• 9.1 Обзор общего интерфейса приложения сенсорной сети

• 9.2 Обязательные операции

• 9.3 Дополнительные операции

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

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

Приложение ДА (справочное) Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте...........................................................................................................................29

Приложение ДБ (справочное) Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта...................................30

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

Введение

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

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

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

ПНСТ 422—2020 (ИСО/МЭК 30128:2014)

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

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

СЕТИ СЕНСОРНЫЕ

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

Information technology. Sensor networks. Generic sensor network application interface

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

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

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

Настоящий стандарт содержит:

• • описание эксплуатационных требований к приложениям общей сенсорной сети;

• • описание возможностей сенсорной сети;

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

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

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

ГОСТ Р 56947/ISO/IEC/IEEE 21450:2010 Информационные технологии. Интерфейс интеллектуального преобразователя для датчиков и исполнительных устройств. Общие функции, протоколы взаимодействия и форматы электронной таблицы данных преобразователя (ЭТДП)

ГОСТ Р 57668 (ИСО 19115-1:2014) Пространственные данные. Метаданные. Часть 1. Основные положения

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

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

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

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

• 3.1 непрерывный режим (continuous mode): Режим запроса сенсорных данных со значением длительности d и значением интервала t.

• 3.2 режим событий (event mode): Режим запроса сенсорных данных с условиями события, при котором сенсорные сети проводят сбор и передачу сенсорных данных только при соблюдении условий события.

• 3.3 мгновенный режим (instant mode): Режим запроса сенсорных данных для немедленного од-некратного ответа от сенсорной сети.

• 3.4 режим включения (onTime mode): Режим запроса сенсорных данных в определенный промежуток времени.

• 3.5 координатор PAN (PAN coordinator): Устройство, которое отвечает за формирование и обслуживание PAN.

• 3.6 режим pull (pull mode): Режим доставки сенсорных данных при наличии запроса на доставку.

• 3.7 режим push (push mode): Режим доставки сенсорных данных при отсутствии запроса на доставку.

Примечание — Возможна реализация, когда доставка сенсорных данных в режиме push инициируется и останавливается запросом.

• 3.8 клиент сенсорной сети; SNC (sensor network client: SNC): Программное обеспечение приложения. которое использует информацию, предоставленную сенсорной сетью.

• 3.9 ресурс сенсорной сети (sensor network resource): Сущность сенсорной сети, которая может быть шлюзом сенсорной сети, координатором PAN (при наличии), сенсорным узлом или преобразователем.

• 3.10 преобразователь (transducer): Устройство преобразования энергии одного типа в другой, откалиброванное для минимизации ошибок в процессе преобразования, которое может быть датчиком или исполнительным устройством.

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

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

АСН.1 — абстрактная синтаксическая нотация версии 1 (Abstract Syntax Notation One. ASN.1);

ЭДТП — электронная таблица данных преобразователя (Transducer Electronic Data Sheet. TEDS): CoAP — ограниченный протокол уровня приложений (Constrained Application Protocol):

DNS — система доменных имен (Domain Name System);

NAK — отсутствие подтверждения приема (Negative Acknowledge);

PAN — персональная сеть (Personal Area Network);

SensorML — язык сенсорной модели (Sensor Model Language);

SNC — клиент сенсорной сети (Sensor Network Client):

SWE — реализация возможностей сенсора через Интернет (Sensor Web Enablement).

• 5 Обзор приложений сенсорных сетей

  • 5.1 Модель связи

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

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

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

и* - интерфейс X

•*-----► - интерфейс Y

_ интерфейс Z

Рисунок 2 — Модель связи: одна сенсорная сеть и множество поставщиков служб сенсорной сети

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

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

Шлюз сенсорной сети преобразует сообщения поставщиков служб сенсорной сети в сообщения сенсорных сетей (например, сообщения ZigBee. Bluetooth. СоАР и т. д.) и наоборот. В некоторых случаях шлюз сенсорной сети должен проводить синхронизацию времени для доставки сообщений на сенсорные узлы. Это связано с тем, что. когда поставщик служб сенсорной сети отправляет сообщение на сенсорные узлы, сенсорные узлы могут находиться в режиме сна для экономии энергии. В этом случае шлюз сенсорной сети для сохранения и пересылки сообщений на сенсорные узлы должен знать жизненный цикл каждого сенсорного узла. При регистрации сенсорного узла или преобразователя у поставщика служб сенсорной сети, шлюз может потребовать дополнительную информацию от сенсорного узла в сообщении регистрации для того, чтобы внести информацию в иерархическую топологию. Если шлюз является высокопроизводительным, на нем могут проводиться сложные операции от менее производительных сенсорных узлов. В некоторых случаях вычислительные возможности сенсорной сети определяются вычислительными возможностями шлюзов. Таким образом, шлюзы сенсорных сетей играют очень важную роль в сенсорных сетях и отличаются от шлюзов в других областях применения.

• 5.2 Операции клиента сенсорной сети

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

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

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

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

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

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

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

• 5.2.2 Оперирование сенсорными данными

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

Существуют различные способы сбора сенсорных данных в сенсорных сетях. Передача собранных сенсорных данных проводится двумя способами. Одним способом является отправка собранных сенсорных данных без учета конкретных запросов от клиентов сенсорной сети, что называется режимом push. Другим способом является отправка сенсорных данных в соответствии с конкретными запросами клиентов сенсорной сети, что называется режимом pull. Режим pull далее подразделяется на мгновенный режим, непрерывный режим и режим событий в зависимости от характеристик запроса от клиентов сенсорной сети. Клиенты сенсорной сети могут запрашивать сенсорные данные только один раз (мгновенный режим), в режиме повторения (непрерывный режим), только при некоторых событиях (режим событий) или в определенный промежуток времени (режим включения).

5.2.22 Режим push

На рисунке 3 показано оперирование сенсорными данными в режиме push.

• 1) сбор 2) периодическая передача

собранных сенсорных данных

Рисунок 3 — Сбор сенсорных данных: режим push

Сенсорная сеть собирает и передает сенсорные данные на основе своих настроек сбора и передачи. Оперирование сенсорными данными в режиме push может быть реализовано двумя способами. В первом способе сенсорная сеть передает сенсорные данные при подключении к клиенту сенсорной сети. При втором способе сенсорная сеть начинает отправлять сенсорные данные при получении команды «старт» и прекращает отправлять при получении команды «стол» от клиента сенсорной сети. В этом случае команды «старт» и «стоп» выдаются клиентом сенсорной сети, но это не меняет настройки сенсорной сети по сбору и передаче сенсорных данных.

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

• 5.2.2.3 Режим pull: мгновенный режим

На рисунке 4 изображен мгновенный режим оперирования сенсорными данными в режиме pull.

• 1) запрос на сбор сенсорных данных е реальном времени

• 2) сбор 3) передача собранных сенсорных дажых

Рисунок 4 — Сбор сенсорных данных: режим pull — мгновенный режим

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

Мгновенный режим является самой базовой операцией режима pull. Мгновенный запрос сенсорных данных может включать в себя условия. Например, клиент сенсорной сети делает запрос с условием измерить значение температуры места No 1. только если значение температуры превышает 30 °C. Тогда сенсорная сеть отправляет значение температуры, только если значение температуры превышает 30 ’С. Если запрос включает условия, сенсорная сеть проверяет условия перед отправкой собранных сенсорных данных. Возможность проверки условий является дополнительней функцией сенсорных сетей. Поэтому сенсорная сеть должна заранее информировать клиентов сенсорной сети о возможности проверки условий.

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

• S.2.2.4 Режим pull: непрерывный режим

На рисунке 5 изображен непрерывный режим оперирования сенсорными данными в режиме pull.

Клиент сенсорной сети отправляет запрос на сбор сенсорных данных. После получения запроса сенсорная сеть проводит сбор сенсорных данных при каждом значении интервала t в течение значения d длительности и периодически передает собранные сенсорные данные клиенту.

1) запрос на периодический сбор сенсорных данных в соответствии с интервалом и длительностью

Рисунок 5 — Сбор сенсорных данных: режим риН - непрерывный режим

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

По сравнению с мгновенным режимом ожидаемая вычислительная сложность сенсорных сетей для выполнения непрерывного режима работы выше.

• 5.2.2.5 Режим pull: режим событий

На рисунке 6 изображено оперирование сенсорными данными в режиме pull — режиме событий.

• 2) сбор и проверка условий »

• 3) если условия соблюдены, то отправка сенсорных данных, в противной случае отправка отсутствует

• 4) сбор и проверка условий .. .■». »

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

Рисунок 6 — Сбор сенсорных данных: режим pull - режим событий

Клиент сенсорной сети отправляет запрос на сбор и отправку сенсорных данных только при соблюдении указанных условий. Условия задаются клиентом сенсорной сети. Различие между режимом событий и другими режимами pull с условиями заключается в том. что условия в режиме событий являются обязательными. Запросы сенсорных данных в режиме событий обрабатываются сенсорной сетью непрерывно до тех пор. пока клиент сенсорной сети не сделает запрос на остановку обработки. Сенсорная сеть продолжает сбор сенсорных данных на основе настроек сбора, как в режиме push, и проверяет условия клиента. Например, клиент сенсорной сети запрашивает данные о температуре в сенсорной сети № 1. только когда наблюдаемые значения температуры превышают определенный порог, чтобы включить систему охлаждения. Тогда клиент отправляет запрос «отправка данных о температуре, собранных в сенсорной сети № 1. только если значение температуры выше 30 ’С».

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

• S.2.2.6 Режим pull: режим включения

На рисунке 7 изображено оперирование сенсорными данными в режиме pull — режиме включения.

1) запрос на отправс/ сенсорных данных а опрсдепенный промежуток времени

2) сбор сенсорных данных * -----------------

в определенный промежуток времени 3) передача сенсорных данных

Рисунок 7 — Сбор сенсорных данных: режим pull — режим включения

Клиент сенсорной сети отправляет запрос на сбор сенсорных данных в определенный промежу-ток времени, и сенсорная сеть проводит сбор сенсорных данных в указанное время. Режим включения используется совместно с другими режимами: запросом на сбор сенсорных данных в мгновенном режиме. непрерывном режиме или режиме событий или оперированием исполнительным устройством. Например, если запрос сенсорных данных в мгновенном режиме включает в себя поле промежутка времени, то сенсорная сеть должна обработать запрос в мгновенном режиме в указанное время. При обработке в режиме включения очень важна синхронизация времени между клиентами сенсорной сети и сенсорными сетями.

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

• 5.2.3 Оперирование исполнительными устройствами

На рисунке 8 изображено оперирование исполнительными устройствами.

1) запрос на исполнение на основе параметров исполнения

2) испопнеюю з) передача результата исполнения

Рисунок 8 — Оперирование исполнительными устройствами

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

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

Сложность оперирования исполнительным устройством пропорциональна сложности параметров исполнения. Детальная конструкция исполнительных устройств не рассматривается в настоящем стандарте ввиду разнообразия типов и параметров исполнительных устройств.

• 5.2.4 Мониторинг и контроль сенсорной сети

На рисунке 9 представлены мониторинг и контроль сенсорной сети.

1) запрос информации о статусе (опционально)

4) потребность а контроле

• 3) передача информации о статусе сенсорной сети

S) запрос контроля сенсорной сети

• 6) контроль сенсорной сети

• 7) передача результата контроля

Рисунок 9 — Мониторжг и контроль сенсорной сети

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

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

• 6 Возможности сенсорной сети

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

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

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

• 7 Защищенность

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

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

Вопросы защищенности не рассматриваются в настоящем стандарте и являются объектом стандартизации профильных национальных технических комитетов.

• 8 Модель сенсорных данных и метаданных

Настоящий стандарт не определяет конкретную модель сенсорных данных и метаданных сенсорной сети. Для сенсорных данных может применяться структура спецификации, представленная в 9.2.3. Для метаданных сенсорной сети могут применяться SensorML SWE и ЭДТП. определенные в ГОСТ Р 56947 и в приложении А (см. также (2), [3]).

Примечания

• 1 Схема реализации покрытия определена е [4].

• 2 Метаданные для географической информации определены в ГОСТ Р 57668.

• 9 Спецификация общего интерфейса приложения универсальной сенсорной сети

  • 9.1 Обзор общего интерфейса приложения сенсорной сети

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

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

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

Общий интерфейс приложения сенсорной сети (обязательный)^

sensxigValueRpt передается клиенту сенсорной сети в соответствии с выбранным режимом оперирования

deReg tsterResourceReqO

Клиент сенсорной сети ¹ удаляет метаданные сенсорной сети из внутренней памяти после отмеш регистрации сенсорной сети

Рисунок 10 — Обязательный интерфейс приложения сенсорной сети

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

Рисунок 11 — Дополнительный интерфейс приложения сенсорной сети

• 9.1.2 Основная структура

Общий интерфейс приложения сенсорной сети определяется в виде набора сообщений. Все сообщения выражены с использованием нотации АСН.1. Структура сообщения приведена в таблице 1.

Примечание — Компиляторы АСН.1 создают коды уровня реализации с интерфейсами, определенными а качестве входных данных (см. [5]).

Таблица 1 — Основная структура сообщения

Все сообщения отформатированы в соответствии с основной структурой.

• 9.1.3 Типы датчиков и единицы измерения

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

• 9.2 Обязательные операции

9.2.1 Регистрация

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

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

В таблице 2 представлена структура сообщения регистрации, в таблице 3 показана информация сообщения регистрации.

Таблица 2 — Структура сообщения регистрации

RegiSterResourceType Printabl&SLring(“GATENODE"I"PAN"I"SENSORNODE”| "TRANSDUCER")

RegiSterResourceReq SEQUENCE {

description GateNode, resourceType RegiSterRasourceType DEFAULT "GATENODE** I

IDList SEQUENCE SIZE(1..MAX) OF PrintableString

RetCode PrintableStrlngCSUCCESS'l "BADREQUEST" i "ERROR" i "UNDEFINED'’ | "STORED")

RegisterResourceRes SEQUENCE I retCode RetCode, idList IDLiSt

I

Таблица 3 — Информация сообщения регистрации

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

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

При регистрации ресурса сенсорной сети у клиента сенсорной сети ресурс может предложить свой идентификатор, или клиент сенсорной сети может назначить уникальный идентификатор ресурсу. В качестве схемы идентификации для сенсорных сетей может использоваться иерархическая структура. например «gatenodeld: panld: nodeld: transducerld». Каждый идентификатор должен быть уникальным в пределах узла-родителя: transducerld является уникальным для сенсорного узла с noteld, noteld уникален для PAN с идентификатором panld. panld является уникальным для шлюза с gatenodeld. gatenodeld является уникальным идентификатором шлюза, и для этого требуется обеспечение уникальности gatenodeld в домене службы. Для обеспечения уникальности идентификатора шлюза может использоваться DNS или другие механизмы обеспечения уникальности идентификаторов шлюза в домене служб. Преимущество иерархической схемы идентификации состоит в том, что шлюзы, координаторы PAN и сенсорные узлы свободны от управления таблицей отображения идентификаторов.

Таблица 4 показывает пример схемы поля description шлюза сенсорной сети.

Таблица 4 — Пример поля description шлюза

SupportedTxansportPxotocol PrlntdbleStrIng(“XML_OVER_TCP"I ”XML_OVER_UDP”I"XML_OVER^ HTTP"i“TEXT_OVER_TCP"]

SupportedTranspertProtOCOlLiSt SEQUENCE OF SupportedTransportProtceol

SupportedCcewand PrintableString("COMMAND_PUSH" | "COMMAND—INSTANT" i “COMMAND_EVENT" I “COMMAND—CONTINUOUS" I “COMMAND-CONTROL" I “COMMAND—MONITORING" | "COMMAND-ACTUATION”)

SupportedCoomandLlSt SEQUENCE OF SupportedConsand

SupportedCoeciandAttxibute PxintableStrlng (“ATTRIBUTE-CONDITION" | "ATTRIBUTE-

FUNCTION" I “ATTRIBUTE-DURATION" I “ATTRIBUTE—SHUTDOWN" | “ATTRIBUTE-RESET" I "ATTRIBUTE^ REBOOT" 1 “ATTRIBUTE—START—SENSING" I "ATTRIBUTE_STOP_SENSING”I"ATTRIBUTE_PAN_ID_CHANGE"T “ATTRIBUTE_CHANNEL_ID_CHANGE")

SupportedCctranandAttributeLlst SEQUENCE OF SuppbxtedCbercnandAttxlbute

GateNodeSuppoxtedOperationLiBt SEQUENCE (

supportedCootnandLlst Supper tedCoecnandListi supportedCocmandAttxlbuteLlst SuppertedCocreaandAttrlbuteLlst

I

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

Time SEQUENCE |

time INTEGER<0 .. MAX), unit TimeUnit DEFAULT "SEC" I

Location SEQUENCE | longitude REAL, latitude REAL, altitude REAL

I

MonitoringMode :PrintableString<"MONITORING_₽ULL"I”MONITORING_PUSH")

GateNode SEQUENCE { id PrintableString, — format: host name or ip url (0) PrintableString OPTIONAL, manufacturer PrintableString OPTIONAL, productNo [1] PrintableString OPTIONAL, location Location OPTIONAL, dateTime (2J UTCTime OPTIONAL, supportedTransportProtocolList (3j SupportedTransportProtocolList OPTIONAL, supportedOperationList (4] GateNodeSupportedOperationList, panList [5| PanList OPTIONAL, monitoringMode (6] MonitoringMode OPTIONAL, monitoringperiod INTEGERS .. MAX) OPTIONAL — in seconds

J

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

• 9.2.2 Отмена регистрации

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

В таблице 5 показана структура сообщения отмены регистрации, в таблице 6 показана информация сообщения отмены регистрации.

Таблица 5 — Структура сообщения отмены регистрации

DeRegisterResourceReq SEQUENCE | idList IDList i* список идентификаторов для отмены регистрации у клиентов сенсорной сети •/ I

DeRegisterResourceRes SEQUENCE |

retCode RetCode, idList IDList I

Таблица 6 — Информация сообщения отмены регистрации

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

• 9.2.3 Передача сенсорных данных

Передача сенсорных данных — это операция доставки собранных сенсорных данных клиенту сенсорной сети. Способ отправки сенсорных данных зависит от режима оперирования с сенсорными данными.

В таблице 7 показана структура сообщения передачи сенсорных данных, в таблице 8 показана информация сообщения передачи сенсорных данных.

Таблица 7 — Структура сообщения передачи сенсорных данных

SensingValueRpt SEQUENCE (

cow-andlD INTEGER(0. .MAX) OPTIONAL,

sensingVa’ueList SEQUENCE OF SensingValueList

Таблица 8 — Информация сообщения передачи сенсорных данных

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

Таблица 9 — Пример структуры сенсорных данных

Function PrintableStrlng(“MIN" ! “MAX" t “AVG" f “SUM")

SensingValue SEQUENCE (

targetID PrintableStrlng, /• идентификатор датчика */

sensorType PrintableStrlng, /• тип датчика •/

value PrintableStrlng, I- измеренное значение •/

function Function OPTIONAL /’примененная функция агрегирования значения'/

SensingValueList SEQUENCE (

tineStanp PrintableStrlng, /' время отправки */

nodeID PrintableStrlng, /' идентификатор сенсорного узла •/

values SEQUENCE S12£(1..MAX) OF SensingValue /* список сенсорных данных, собранных сенсорным узлом*/

• 9.3 Дополнительные операции

9.3.1 Команда мгновенного режима

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

В таблице 10 показана структура сообщения команды мгновенного режима, в таблице 11 показана информация сообщения команды мгновенного режима.

Таблица 10 — Структура сообщения команды мгновенного режима

Function PrintabieString("MIN" | "MAX" I "AVG" I "SUM")

LogicalOp FrintableString("OR” | "AND")

RelationalOp PrintableString(“GT" I “GE" I “LT” I "LE" I "EQ" | “NE”)

SensingType SEQUENCE {

function (0) Function OPTIONAL, l* функция агрегирования для сенсорных данных */ sensorType [1J PrintabieString, /* тип сенсорных данных*/ unit PrintabieString /• единица измерения сенсорных данных ♦/ I

SensingTypeList SEQUENCE OF SensingType

ConditionType SEQUENCE |

type PrintabieString, /* тип сенсорных данных */

relationaiOp RelationalOp,

value PrintabieString,

logicalOp LogicalOp OPTIONAL I

ConditionList SEQUENCE OF ConditionType

InstantCmd SEQUENCE |

commandID INTEGERfO..MAX), /• идентификатор команды */

targetIDLiat IDLiat, /♦ список идентификаторов ресурсов для выполнения команды •/ sensingTypeList SensingTypeList, /• список типов датчиков */ actlonTime DTCTime OPTIONAL, /* если установлено, то команда обрабатывается в указанное время */

conditionList ConditionList OPTIONAL /* список условий при наличии •/ I

Таблица 11 — Информация сообщения команды мгновенного режима

• 9.3.2 Команда непрерывного режима

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

8 таблице 12 показана структура сообщения команды непрерывного режима, в таблице 13 пока* зана информация сообщения команды непрерывного режима.

Таблица 12 — Структура сообщения команды непрерывного режима

ContinuOusCmd SEQUENCE {

ccewandID INTEGER(0. .MAX),

targetIDLlSt IDLlSt,

sensingTypeList SenaingTypeList, actionTime OTCTlme OPTIONAL, /• если установлено, то команда обрабатывается в указанное время •/

period Tine,

duration (0) Time OPTIONAL,

conditionList fl] ConditionLlSt OPTIONAL

Таблица 13 — Информация сообщения команды непрерывного режима

• 9.3.3 Команда режима событий

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

8 таблице 14 показана структура сообщения команды режима событий, в таблице 15 показана информация сообщения команды режима событий.

Таблица 14 — Структура сообщения команды режима событий

EventCmd SEQUENCE {

ccewandID INTEGER(0..MAX),

targetIDLlst IDLlSt,

sensingTypeLlst SensingTypeList,

actionTime UTCTime OPTIONAL, !* если установлено, то команда обрабатывается в указанное время •/

conditionList ConditionList

Таблица 15 — Информация сообщения команды режима событий

• 9.3.4 Команда остановки

Команда остановки предназначена для остановки обработки команды. Используя StopCmdReq. клиент сенсорной сети может запросить остановку обработки ContinuousCmd. EventCmd, оперирования сенсорными данными в режиме push, оперирования исполнительными устройствами или MonitoringCmd.

В таблице 16 показана структура сообщения команды остановки, в таблице 17 показана информация сообщения команды остановки.

Т аблица 16 — Структура сообщения команды остановки

StopCmdReq SEQUENCE I

commandID INTEGER(0 .. MAX) /* отслеживается уникальность, чтобы избежать дублирования •/

I

StopCmdRes SEQUENCE I retCode RetCode

I

Таблица 17 — Информация сообщения команды остановки

9.3.S Команда исполнения

Команда исполнения — это сообщение целевому исполнительному устройству действовать в соответствии с параметрами исполнения.

В таблице 18 показана структура сообщения команды исполнения, в таблице 19 показана информация сообщения команды исполнения.

Таблица 18 — Структура сообщения команды исполнения

ActuationCmd SEQUENCE (

cocnandZD INTEGER(0..MAX),

targetlDList IDList, /* идентификатор целевого ресурса •/

actuatorType PrintableString,

actionvalue PrintableString

actionTime UTCTime OPTIONAL, /* если установлено, то команда обрабатывается в указанное время •/

Actuationvalue SEQUENCE (

targetID PrintableString,

actionvalue PrintableString

)

ActuationValueList SEQUENCE (

actuationValue SEQUENCE SiZE(l..MAX) OF Actuationvalue )

ActuationRpt SEQUENCE (

coemandID INTEGER(0. .MAX),

actuationValueList ActuationValueList

Таблица 19 — Информация сообщения команды исполнения

• 9.3.6 Команда мониторинга

Команда мониторинга — это сообщение статуса мониторинга сенсорных сетей. Реализация может происходить двумя способами. В первом способе MonitoringRpt запускается в режиме повтора без запроса от клиента сенсорной сети. В другом способе используются MonitoringCmd и MonitoringRpt. Способ является вопросом реализации и должен быть заранее объявлен клиентам сенсорной сети.

В таблице 20 показана структура сообщения команды мониторинга, в таблице 21 показана инфор-мация сообщения команды мониторинга.

Таблица 20 — Структура сообщения команды мониторинга

Таблица 21 — Информация сообщения команды мониторинга

• 9.3.7 Контроль ресурсов

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

8 таблице 22 показана структура сообщения контроля ресурсов, в таблице 23 показана информа-ция сообщения контроля ресурсов.

Таблица 22 — Структура сообщения контроля ресурсов

ResourceCti’Req SEQUENCE ( targetID PrlntableString, controlType SupportedCoetnandAttribute, /• свойство для контроля */ controlvalue PrlntableString

ResourceCtriRes SEQUENCE ( retCode RetCode, raaultValue PrlntableString

Таблица 23 — Информация сообщения контроля ресурсов

Примечание — Клиент сенсорной сети может инициировать сбор сенсорных данных в режиме push, используя ResourceCtrIReq с controlType = “ATTRIBUTE.START.SENSING". Клиент может прекратить сбор сенсорных данных в режиме push, используя ResourceCtrIReq с controlType ="ATTRIBUTE.STOP.SENSING".

• 9.3.8 Пользовательское сообщение

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

В таблице 24 показана структура пользовательского сообщения, в таблице 25 показана информация пользовательского сообщения.

Таблица 24 — Структура пользовательского сообщения

UserDeflnedMsg SEQUENCE I sourcelD PrintableString, l* идентификатор отправителя сообщения */ targetID PrintabieString, message PrintableString 1

Таблица 25 — Информация пользовательского сообщения

• 9.3.9 Уведомление об отклонении

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

В таблице 26 показана структура сообщения уведомления об отклонении, в таблице 27 показана информация сообщения уведомления об отклонении.

Таблица 26 — Структура сообщения уведомления об отклонении

Rejectcode :PrintableStringCBADREQUEST" I "NOT_SUPPORTED_COMMAND" | "ERROR") RejectNotify SEQUENCE | commandID INTEGER(0 .. MAX), rejectcode Rejectcode, rejectMessage PrintableString OPTIONAL

I

Таблица 27 — Информация сообщения уведомления об отклонении

• 9.3.10 Уведомление NAK

Уведомление NAK — это уведомление отправителя сообщения о наличии ошибки в сообщении. Отправителями уведомления могут быть клиенты сенсорной сети и ресурсы сенсорной сети.

В таблице 28 показана структура сообщения уведомления NAK. в таблице 29 показана информация сообщения уведомления NAK.

Таблица 28 — Структура сообщешя уведомления NAK

NakNotify SEQUENCE I message PrintableString, messageType MessageType OPTIONAL I

Таблица 29 — Информация сообщения уведомления NAK

Описание сенсорной сети (пример)

А.1 Описание шлюза

• - file: gateNodeDesc.asnl

• - define interfaces between USN Middleware and G/W

• - define gateway description

IS0IEC30128-GateNodeDesc DEFINITIONS IMPLICIT TAGS ::- BEGIN

EXPORTS GateNode;

IMPORTS Location, HonitoringHode, SupportedCommandList, SupportedCcernandAttrIbuteLlst FROM ISOIEC30128-Types

PanList FROM ISOIEC3O12fi-PanDesc;

SupportedTransportProtocol :PrintableString<"XML_OVER_TCP" I "XML_OVER_UDP" I "XML_ OVER_HTTP" I "TEXT_OVER_TCP”)

SupportedTransportProtocolList SEQUENCE OF SupportedTransportProtocol

SupportedTransportConnectionControlList SEQUENCE OF SupportedTransportProtocol

GateNodeSupportedOperatlonLlst ::- SEQUENCE ( SupportedCommandList SupportedCommandList, supportedCommandAttrIbuteLlst SupportedCommandAttribuceList I GateNode SEQUENCE (

id PrlntableString, -- format: host name or Ip

url [0] PrlntableString OPTIONAL, manufacturer PrlntableString OPTIONAL, productNo (1) PrlntableString OPTIONAL, location Location OPTIONAL, dateTime (2J UTCTime OPTIONAL, supportedTransportProtocolList (3) SupportedTransportProtocolList OPTIONAL, supportedOperationList Hl GateNodeSupportedOperatlonLlst OPTIONAL, panList (51 PanList OPTIONAL, monitoringMode (6| MonitoringMode OPTIONAL, monitorlngPeriod INTEGER(0 .. MAX)OPTIONAL — in seconds

I END

A.2 Описание PAN

• - file: panDesc.asnl

• - define PAN description

ISOIEC3O128-PanDesc DEFINITIONS IMPLICIT TAGS BEGIN

EXPORTS Pan, PanList;

IMPORTS UnsignedByte, SupportedCommandList, SupportedCommandAttrIbuteLlst FROM IS0IEC30128-Types

SensorNodeList FROM IS0IEC30128-SensorNodeDesc;

Pan ::- SEQUENCE | id Numericstring, — format: number topology (0] PanTopology OPTIONAL, protocolstack |1) PanProtocolStack OPTIONAL, panChannel (2) UnsignedByte OPTIONAL, supportedChannelList [3| PanChannelList OPTIONAL, supportedTopologyList (41 PanTopologyList OPTIONAL, 24

suppoxtedProtocolStackLlst (S) PanProtocolStackList OPTIONAL, suppertedOperationList (6] PanSupportedOperationList OPTIONAL, sensoxNodeList (7) SensorNodeLlst OPTIONAL ) PanList SEQUENCE SIZE(1..MAX) OF Pan PanChannelList ::- SEQUENCE OF UnsignedByte PanTopology PrlntableString("TREE" I "MESH" ; "STAR") PanTopologyList ::- SEQUENCE OF PanTopology PanProtocolStack PrlntableString("802.15.4", "ZIGBEE" I "BLUETOOTH" i "LPJftFI" I "PROTOCOL_RES1" | "PROTOCOL_RES2" "PROTOCOL_RES3" "PROTOCOL_RES4" 1 "PROTOCOL_RES5~1

PanProtocolStackList ::• SEQUENCE OF PanProtocolStack PanSupportedOperationList ::- SEQUENCE {

suppoxtedCocrtnandList SupportedCoanandList, suppoxtedCoetnandAi.tributeList Suppox tedCoaxnandAttr ibuteList END

A.3 Описание сенсорного узла

• - file: sensorNodeDesc.asnl

• - define sensor node description ISOIEC30128-SensorNodeDesc DEFINITIONS IMPLICIT TAGS BEGIN EXPORTS SensorNode, SensoxNodeList;

IMPORTS MonitoringMode, Location, SupportedCommandList, SupportedCotnmandAttributeList FROM ISOIEC30128-Types

TransducerList FROM ISOIEC30128-TransducexDesc;

SensorNode SEQUENCE ( id Numericstring, — resource identification, format: number gid PrlntableString, — global identification monitoringMode (0J MonitoringMode OPTIONAL, monitoringperiod (1) INTEGER(0 .. MAX) OPTIONAL, manufacturei (2) PrlntableString OPTIONAL, productNo (3J PrlntableString OPTIONAL, location [4] Location OPTIONAL, role (SJ SensorNodeRole OPTIONAL, roieList (6) SensorNodeRoleList OPTIONAL, parentNodeList (71 ParentNodeList OPTIONAL, supportedOperationList (8] SensorNodeSupportedOperationList OPTIONAL, transducerList (91 TransducerList OPTIONAL ) SensoxNodeList SEQUENCE SIZE(1..MAX) OF SensorNode SensorNodeRole PrlntableString("COORDINATOR" I "ROUTER" I "LEAF") SensorNodeRoleList ::- SEQUENCE OF SensorNodeRole ParentNode ::- SEQUENCER

parentNode INTEGER(0..MAX)

ParentNodeList ::- SEQUENCE SIZE(1..MAX) OF ParentNode SensorNodeSupportedOperationList ::• SEQUENCE ( supportedCoetnandList SupportedCoomandList, supportedCoetnandAttributeList SupportedCocmandAttributeList > END

A.4 Описание преобразователя

• - file: transducexDesc.asnl

• - define transducer description ISOIEC30128-TransducerDesc DEFINITIONS IMPLICIT TAGS ::- BEGIN EXPORTS TransducerList, Transducer;

IMPORTS DataType, SupportedCommandList, SupportedCommandAtcributeList FROM ISOIEC30128-Types; Transducer::» CHOICE ( sensor (O)Sensor, actuator (1) Actuator

I

TransducerList:SEQUENCE SI2E(1..MAX) OF Transducer Level INTEGERS .. MAX) LevelList SEQUENCE OF Level Sensor :: - SEQUENCE | Id Numericstring, — transducer identification, format: number manufacturer (0] PrintableString OPTIONAL, productNo PrintableString OPTIONAL, range |lj Range OPTIONAL, level |2j LevelList OPTIONAL, supportedOperationList TransducerSupportedOperationList, transducerType |3J TransducerType DEFAULT "SENSOR", type PrintableStringfFROM <”A”.."2" I "a".."a")), unit PrintableStringfFROM <"A”.."Z" | "a".."a")), dataType DataType (Actuator SEQUENCE ( id Numericstring, -- transducer identification, format: number manufacturer |O) PrintableString OPTIONAL, productNo PrintableString OPTIONAL, range |1] Range OPTIONAL, level 12] LevelList OPTIONAL, supportedOperationList TransducerSupportedOperationList, transducerType (3) TransducerType DEFAULT "SENSOR”, type PrintableStringfFROM <"A”.."Z" I "a".."a" )), unit PrintableStringfFROM <”A".."2” I "a”.."a" )), dataType DataType I Range SEQUENCE( min R£AL(O..MAX), max REAL<0..MAX), Offset INTEGER<1 .. MAX) OPTIONAL!

TransducerType ::- PrintableString<“SENSOR" | "ACTUATOR") TransducerSupportedOperationList- SEQUENCE I suppor tedCommandList Suppor tedCommandList, supportedCommandAttributeList SupportedCommandAttributeList I

END

Тип датчика и единица измерения (пример)

<?xml version«»*1.0" encoding-"euc-kr"??

<xsdг schema xmlnsrxsd-"httprhttps://www.w3.org/2001/XMLSchema"

xmlnsrutran-"httpr//www.ieoiec30128.org/cosmos/resource/unitOfTrensducerType"

targetHa»espace-"httpr//www.isolec30128.org/cosmos/resource/unitOf TransducerType" elec>entFormDefault-"qualined"?

<xsd:simpleType name»"tSensorType"> <xsd:restriction base-"xsdratting"? ^1 wwwwwwwwwwwwwwwwwwwwwwwwwwwwww

<!—Security -->

<1 w WWW — WWW w WWW wwwww w wwww ww wwww

<xsdenumeration value-"EMF"/?

<xsdrenumeration value-"VOCS"/?

<xsdenumerat ion vaiue-"CO2"/?

<xsdrenumeration value»"GEIGER_COUNTER"/?

<xsd enumeration value-"MAGNETIC"/?

<xsdenumeration value-"HEAT_RAY"/?

<xsd enumeration value-"INFRARED_RAY"/?

<!-- ——————

<!-- Environment --?

<!--

<xsdenumeration vaiue»"TEM₽ERATURE’^r/>

<xsd:enumeration value-"ILLUMINATION"/?

<xsdenumeration vaiue-"NOISE"/>

<xsdenumeration value-"HUMIDITY"/>

<xsdenumeration vaiue-"WIND_SPEED"/>

<xsdenumeration value-"’JLTRA_VIOLET"/>

<!-Heaith —>

<| -• WW w WOO WWW ■■4RWWWWWW w W

<xsdenumeration vaiue-"DIASTOLIC_BLOOD_?RESSURE"/>

<xsdenumeration value-"SYSTOLIC_BLOOD_₽RESSURE"/>

<xsdenumeration value-"BLCOD_GLUCOSE"/>

<xsdenumeration value-"WEIGHT"/>

<xsdenumeration vaiue»"WEIGHT_CHANGE"/>

<xsdenumeration value-"BOPY_FAT"/>

<xsd enumeration vaiue»"BODY_TEMPERATURE"/>

<xsdenumeration value-"₽ASSOMETER"/>

<xsdenumeration vaiue-"OXYGEN_SATURATION"/>

<xsdenumeration value-"PULSE"/>

^-Miscellaneous —>

<i__ ————————

<xsdrenumeration value-"LONGITUOE"/>

<xsdenumeration value-"LATITUDE"/>

<xsdrenumeration vaiue«"ALTITUDE"/>

<xsdenumeration value-"BATTERY"/?

<xsd renumeration value»"WINt>_DIRECTION"/?

<xsdenumeration value-"RAIN_FALL"/?

<xsdrenumeratlon value-"₽RESSURE"/?

</xsdrrestriction?

</xsdrsimpieType>

<xsdrsimpleType name-"tSensorUnit"?

<xsd:restriction base-”xsd: string**»

<хзб:enumeration value-"SIEVERT~/>

<xed:enumeration value-"WATT_PER_CM2^,“/>

<x3d: enumeration value-“MILLI_GAL’SE"/>

<xed:enumeration value-"PARTS_PER_Mll.LION"/»

<x3d: enumeration value-"MILLIMETERS_OF_MERCURY"/»

<xed:enumeration value-"MILLlGRAMS_PER_DECILITER"/>

<x3d:enumeration value-"KILLOGRAMS"/>

<xed:enumeration value-"PERCENTAG£"/>

<x3d:enumeration value-"CELSIDS"/>

<xed:enumeration value-^LUX"/»

<x3d: enumeration value-*'DECIBEL“/>

<xed:enumeration value-"COUNT"/>

<x3d:enumeration value-"PERCENTAGE_PER_BITPERMINUTES"/>

<X3d: enumeration value«"BEAT_PER_MINUTE'“/>

<x3d:enumeration vaiue-"METER_PER_SECOND"/>

<хзб:enumeration value-"NO_UNlT“/>

<xsd:enumeration value-"MILLIMETERS_PER_K0UR*7>

<xsd:enumeration value-"HECTOPASCAL"/»

<x3d:enumeration value-"ANGLE"/>

</xsd:restriction»

</xad:simpleType>

<xsd:simpleType name***tActuatorType">

<xsd:restriction base-"xsd:string"»

<xsd:enumeration value»”FAUCET"/>

<xsd:enumeration value»”FAN"/»

<xsd: enumeration value»^,’MONITOR”/> </xsd:restriction»

</xsd:3impieType>

<xsd:simpleType name**"tActuatorUnit">

<xsd:restriction base**"xsd:string**»

<xsd:enumeration value-"DIGITAL”/»

<xsd:enumeration value»”ANALOG"/>

<xsd:enumeration value»**STRING"/>

</xsd:restriction»

</xsd:simpleType»

</xsd:scbema>

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

Таблица ДАЛ

Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта

Таблица ДБ. 1

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

[?] ISO/IEC 29182*2:2013 Information technology — Sensor networks: Sensor Network Reference Architecture (SNRA) — Part 2: Vocabulary and terminology (Информационные технологии. Сенсорные сети. Эталонная архитектура для сенсорных сетей (SNRA). Часть 2. Словарь и терминология)

• [2] ISOHEC/IEEE 21451-4 information technology — Smart Transducer Interface for Sensors and Actuators — Mixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats [Информационные технологии. Интеллектуальный интерфейс преобразователей для датчиков и исполнительных устройств. Часть 4. Смешанные протоколы связи и форматы хранения данных преобразователя (TEDS)]

• [3] ISO/IEC/IEEE 21451-7 Information technology — Standard for a Smart Transducer Interface for Sensors and Actuators — Transducers to Radio Frequency Identification (RFID) Systems Communication Protocols and Transducer Electronic Data Sheet Formats [Информационные технологии. Интеллектуальный интерфейс преобразователей для датчиков и исполнительных устройств. Часть 7. Протоколы связи преобразователя с системами радиочастотной идентификации и форматы хранения данных преобразователя (TEDS)]

• [4] ISO 19123:2005 Geographic information — Schema for coverage geometry and functions (Географическая информация. Схема геометрии и функций покрытия)

• [5] ISO/1EC 30128:2014 Information technology — Sensor networks — Generic Sensor Network Application Interface (Информационная технология. Сенсорные сети. Основной интерфейс приложения сенсорной сети)

• [6] ISO 19158:2011 Geographic information — Observations and measurements (Географическая информация. Наблюдения и измерения)

УДК 004.738:006.354

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

БЗ 9—2020

Редактор Н.В. Таланова Технический редактор В.Н. Прусакова Корректор О. В. Лазарева Компьютерная верстка Е.О. Асташина

Сдано а набор 20.07.2020. Подписано а печать 11.08.2020. Формат 60'84’/_в. Гарнитура Ариал. Усл. печ. л. 4.18. Уч.-иад. л. 3.78.

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

ИД «Юриспруденция». 115419. Моема, ул. Орджоникидзе. 11.

www.jurisrzdal.ru y-book@mail.ru

Создано а единичном исполнении во . 117418 Москва. Нахимовский пр-т, д. 31. к. 2.

info@gostinfo.ni