ПНСТ 517-2021 Информационные технологии. Сети сенсорные. Интегрированная среда тестирования

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

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

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

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

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

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

(ISO/IEC 19637:2016, Information technology — Sensor network testing framework, MOD)

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

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

Предисловие

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

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

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

• 4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 19637:2016 «Информационные технологии. Интегрированная среда тестирования сенсорных сетей» (ISO/IEC 19637:2016 «Information technology — Sensor network testing framework». MOD) путем включения структурных элементов, которые выделены в тексте курсивом. Внесение указанных технических отклонений направлено на учет потребностей национальной экономики Российской Федерации.

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

• 5 Некоторые элементы настоящего стандарта могут быть объектами патентных прав. Федеральное агентство по техническому регулированию и метрологии не несет ответственности за установление подлинности каких-либо или всех таких патентных прав

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

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

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

€> ISO. 2016 — Все права сохраняются © IEC. 2016 — Все права сохраняются © Стандартинформ. оформление, 2021

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

Содержание

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

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

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

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

• 5 Общие положения об интегрированной среде тестирования сенсорных сетей

• 5.1 Требования к испытаниям сенсорных сетей

• 5.2 Концептуальная модель интегрированной среды тестирования сенсорных сетей

• 5.3 Менеджер тестирования (TMR)

• 5.4 Агент тестирования (ТА)

• 6 Службы тестирования

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

• 6.2 Взаимодействие модулей через унифицированные службы

• 6.3 Службы данных тестирования (TDSs)

• 6.4 Службы управления тестированием

Приложение А (справочное) Пример испытательной платформы для гибридных сенсорных сетей на основе IPv6

Введение

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

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

• • гетерогенность сенсорной сети. Должна быть проверена совместимость сенсорных сетей, использующих различные протоколы;

• • разнообразие приложений сенсорной сети.

ПНСТ 517—2021 (ИСО/МЭК 19637:2016)

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

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

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

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

Information technology. Sensor networks. Testing framework

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

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

Настоящий стандарт определяет;

• - интегрированную среду тестирования для проведения испытаний на соответствие для гетерогенных сенсорных сетей;

• - общие службы между менеджером тестирования (TMR) и агентом тестирования (ТА) в рамках интегрированной среды тестирования;

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

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

8 настоящем стандарте нормативные ссылки отсутствуют.

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

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

• 3.1 аналитический модуль (analysis module): Логическое устройство в процессе тестирования приложения, которое используется для анализа информации от агента тестирования и модульного теста в зависимости от конкретной стратегии.

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

• 3.3 процесс тестирования приложения (testing application process): Программная функциональная сущность, выполняющая обработку путем объединения тестовых модулей, аналитического модуля и модуля отчетов для выполнения целей тестирования.

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

• 3.4 модуль тестирования (test module): Логическое устройство в процессе тестирования приложения. выполняющее операции в зависимости от заданных требований к тестированию.

• 3.5 испытательная платформа (стенд) (testing platform): Сущность тестирования, которая может интегрировать различные тестовые системы для различных протоколов и технологий.

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

Пример — Платформа может предоставлять тестовые системы на соответствие IPv4 и IPv6.

• 3.6 отчет о тестировании (test report): Логическая единица программного обеспечения в процессе тестирования приложения, которая создает документы в конце тестирования.

• 3.7 объект представления (view object): Логический элемент, предназначенный для обеспечения эффективного доступа к данным в модуле тестирования или аналитическом модуле.

Примечание — Отображается в графическом интерфейсе пользователя.

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

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

АТЕ — вспомогательное тестовое оборудование (auxiliary testing equipment);

OUT — тестируемое устройство (device under test);

IUT — тестируемая реализация (implementation under test);

MIB — база управляющей информации (management information base);

OD — словарь объектов (object dictionary);

SAPs — точки доступа к службам (service access points);

SUT — тестируемая система (system under test);

TA — агент тестирования (test agent);

TAP — процесс приложения тестирования (testing application process);

TDSs — службы данных тестирования (testing data services):

TM — тестовый модуль (test module);

TMR — менеджер тестирования (test manager);

TMSs — службы управления тестированием (testing management services);

VO — объект представления (view object).

• 5 Общие положения об интегрированной среде тестирования сенсорных сетей

  • 5.1 Требования к испытаниям сенсорных сетей

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

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

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

В приложении А приведен пример испытательной платформы для гибридных сенсорных сетей на основе IPv6.

• 5.2 Концептуальная модель интегрированной среды тестирования сенсорных сетей

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

SUT — это система, которая может включать в себя одно тестируемое устройство (DUT) или DUT и другие устройства, используемые для активации поведения конкретного протокола в DUT. что наэы-вается вспомогательным тестовым оборудованием (ATE). DUT должен быть проверен на наличие необходимых реализаций протокола. SUT содержит точки контроля и наблюдения на верхней или нижней границе обслуживания реализаций протоколов, находящихся в OUT для выполнения тестов. Во время проведения тестирования реализации протоколов называются тестируемыми реализациями (IUT). Перед началом выполнения испытаний на соответствие IUT должна быть настроена инструкциями TMR. В сложной среде может использоваться АТЕ для активации DUT. чтобы гарантировать получение ожидаемых ответов от DUT в случае, если IUT не может самостоятельно активировать некоторые конкретные поведения протокола.

Рисунок 1 — Концептуальная модель интегрированной среды тестирования сенсорных сетей

• 5.3 Менеджер тестирования (TMR)

TMR может поддерживать несколько процессов приложения тестирования (ТАР). Каждый ТАР имеет определенную задачу тестирования. Например, могут быть созданы процесс приложения для тестирования конкретного протокола и одновременно другой процесс приложения для другого протокола.

Процесс приложения тестирования разработан на основе компонентов. В ТАР есть пять типов компонентов:

- объект представления;

• • отчет о тестировании;

• * тестовый модуль;

- аналитический модуль;

■ словарь объектов (OD).

На рисунке 2 показаны взаимосвязи пяти компонентов ТАР.

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

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

Объект представления (VO) имеет наборы параметров из ТМ и AM. Объект представления может быть выведен на графический пользовательский интерфейс, что позволяет осуществлять мониторинг в режиме реального времени в течение необходимого периода времени. Объекты представления могут быть сгруппированы для наблюдения за параметрами в соответствующих ТМ и AM. и наблюдаемые параметры могут быть получены из разных ТМ или AM.

База управляющей информации (MIB) хранит все значения объектов тестового модуля, объект представления и отчет о тестировании в TMR. включая объекты управления для ТА. Значения объектов в процессе приложения тестирования могут быть быстро проиндексированы в словаре объектов (OD).

Рисунок 2 — Взаимосвязи компонентов ТАР

• 5.4 Агент тестирования (ТА)

Агент тестирования (ТА) разрабатывается для отдельного протокола и может поддерживать не* сколько реализаций одного и того же протокола. ТА поддерживает любую прямую связь с SUT по одно* му протокопу через тестовый драйвер. Независимость от платформы может быть достигнута испольэо* ванием тестового драйвера. Параметры конфигурации тестового драйвера определены в описании ТА.

Перед выполнением соответствующих тестовых операций ТА должен установить коммуникаци* онное соединение с ТМ в TMR при получении команды запуска от ТМ. ТА получает службы от ТМ и переводит их в соответствующие сообщения в соответствии с протоколом SUT. Структура модели ТА показана на рисунке 3.

• 6 Службы тестирования

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

Службы тестирования делятся на два класса: службы данных тестирования (TDSs) и службы управления тестированием (TMSs). как показано на рисунке4. TMSs может использоваться для создания связи приложений или установки параметров ТА через точки доступа к службе входа управления (ME-SAPs). TDSs следует использовать для реализации процедур тестирования между TMR и ТА через точки доступа к службам ввода данных (DE-SAPs). TMR может передать тестируемые данные и осуществлять контроль тестирования ТА.

Рисунок 4 — Службы тестирования для сенсорных сетей

Службы данных тестирования включают в себя:

• служба EventReport, которая используется для сообщения о сбоях или исключениях в ТА. Содержание отчета может изменяться в зависимости от условий тестирования. Служба EventReport может повторяться до тех пор. пока не будет получена служба EventAck для EventReport:

■ служба EventAck. которая используется для подтверждения приема отдельной службы EventReport. Служба EventAck должна приводить к прекращению повторных служб EventReport для соответствующего отдельного события;

• • служба Read, которая используется для чтения значения объекта из ТМ в TMR или ТА;

• * служба Write, которая используется для записи значения объекта из ТМ в TMR или ТА;

• * служба StartTest. которая используется для запуска тестового задания между ТМ в TMR и ТА. После вызова этой службы запускаются тестовые сценарии;

• * служба StopTest, которая используется для остановки тестового задания между ТМ е TMR и ТА. После вызова этой службы останавливаются все деятельности тестирования;

• • служба Datallploading. которая используется для передачи блока данных от ТА к ТМ в ТМА. Она поддерживает фрагментацию для передачи большого объема данных. Устройство назначения может повторно собрать полученные сообщения;

• • служба DataDownloading. которая аналогична службе Datallploading. Разница в том. что передача блока данных идет от ТМ к ТА;

• • служба StartDownAndUptoading, которая используется для запуска загрузки или выгрузки данных;

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

• - служба ExecuteTesting. которая используется для выполнения тестового сценария.

Службы управления тестированием включает в себя;

« служба Associate, которая предоставляет механизмы создания логического соединения между ТА и ТМ в TMR. Соединение является предусловием для запуска других служб между ТМ и ТА;

• - служба Abort, которая позволяет сбросить логическое соединение между ТМ и ТА. При этом деятельности по передаче данных должны быть остановлены до тех пор. пока не будет установлено новое соединение;

• - служба Sync, которая позволяет установить время для ТА. связанное с ТМ. в TMR. Это позволяет синхронизировать время в тестируемой системе с ограничениями по времени;

• - служба AddressAllocation. которая предоставляет функции для распределения адресов для ТА. ТМ может предоставить уникальную идентификацию для каждого ТА через эту службу;

• * служба Devicestatus, которая используется для произвольной передачи статуса устройства.

• 6.2 Взаимодействие модулей через унифицированные службы

Перед тестированием SUT, ТМ в TMR должен создать коммуникационное соединение с ТА и SUT. Как показано на рисунке 5, ТМ отправляет сообщение с запросом открыть соединение для конкретного протокола и проведения тестирования. Сообщения между ТМ и ТА должны использовать одинаковый протокол. Затем ТА загружает конкретный отдельный протокол и тестовый драйвер для конкретного протокола, используемого в SUT. ТА действует как транслятор протокола между ТМ и SUT. Когда ТМ инициирует прекращение коммуникационных деятельностей, он должен отправить запрос службы Abort к ТА. При получении ответа Abort от ТА соединение успешно освобождается.

Спужба StartTest используется для запуска тестового задания после открытия соединения. ТА и SUT должны распределять ресурсы тестирования и предоставлять необходимые конфигурации тестирования для подготовки к деятельностям тестирования. Тестовые сценарии в тестовых наборах будут выполнены, когда ТА получит запрос ExecuteTesting. Результаты тестирования передаются в ТМ. Если аналитический модуль (AM) сконфигурирован процессом приложения тестирования для связывания с ТА. то он должен получить результаты тестирования для анализа. После завершения тестового задания ТМ отправляет запрос StopTest для завершения задания. Типичная диаграмма последовательности сообщений между модулями показана на рисунке 6.

Рисунок 5 — Схема последовательности создания и освобождения соединения

АЛВНТ TBOCHpCBIHMR

Рисунок 6 — Схема последовательности создания и освобождения соединения

• 6.3 Службы данных тестирования (TDSs)

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

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

Таблица 1 — Службы данных и их SAP

• 6.3.2 Служба EventReport

Служба EventReport предоставляется через EventReport-SAP. EventReport-SAP — это логический интерфейс в приложении, которое выдает EventReport. EventReport является неподтвержденной службой. В таблице 2 представлены простые запросы, поддерживаемые EventReport*SAP. В таблице 3 описаны параметры простых запросов.

Таблица 2 — Простые запросы, поддерживаемые EventReport

Таблица 3 — Параметры простых запросов для EventReport

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

• 6.3.2.1 EventReport.request

Данный простой запрос запрашивает процесс отчета о событии на уровне приложения. Если значение параметра Mode является широковещательным. ConnectlD должен быть установлен в 0; в противном случае это значение идентификации связи, установленное источником.

Параметры данного простого запроса:

EventReport.request{

SourceAddress.

DestinationAddress.

Mode.

ConnectlD.

Priority.

EventID.

EventType,

Timestamp.

AssociatedObjectID.

Length.

Value

}

• 6.3.2.2 EventReportJndication

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

Параметры данного простого запроса:

EventReportJndication {

SourceAddress.

Mode.

ConnectlD.

EventID.

EventType.

Timestamp.

AssociatedObjectID.

Length.

Value

}

• 6.3.3 Служба EventAck

Служба EventAck используется для подтверждения отдельного события. В таблице 4 представлены простые запросы, поддерживаемые EventAck-SAP. В таблице 5 описаны параметры простых запросов.

Таблица 4 — Простые запросы, поддерживаемые EventAck

Таблица 5 — Параметры простых запросов EventAck

• 6.3.3.1 EventAck.request

Если получен дубликат EventReport, то должен быть отправлен дубликат EventAck. Параметр ConnectlD. EventID и AssociatedObjectlD должен совладать с полученным EventReport. Параметры данного простого запроса:

EventAck.request {

SourceAddress.

DestinationAddress.

Mode.

ConnectlD.

Priority,

EventID,

AssociatedObjectlD.

Length.

Result

}

• 6.3.3.2 EventAck.indication

После получения EventAck статус отчета о событии будет очищен. Параметры данного простого запроса:

EventReport.indication{

EventID.

AssociatedObjectlD,

Length.

Result

}

• 6.3.4 Служба Read

Служба Read поддерживает режим связи клиент/сервер. Эта служба обычно используется для получения конфигурации агента тестирования. В таблице 6 представлены простые запросы, поддерживаемые READ-SAP. В таблице 7 описаны параметры простых запросов.

Таблица 6 — Простые запросы. поддерживаемые службой Read

Таблица 7 — Параметры простых запросов для службы Read

• 6.3.4.1 Read.request

Параметры данного простого запроса: Read.request { SourceAddress. DestinationAddress, Mode. ConnectlD. ApplicationlD, ModulelD. ObjectID, Length

}

• 6.3.4.2 Read.tndication

Параметры данного простого запроса: Read.indication { SourceAddress. ConnectlD. ApplicationlD. ModulelD. ObjectID. Length

}

• 6.3.4.3 Read.response

Параметры данного простого запроса: Read.response{ SourceAddress. DestinationAddress. Mode. ConnectlD

AppJicat»onlD.

ModulelD.

ObjectID.

Length.

Data

}

• 6.3.4.4 Read.confirm

Параметры данного простого запроса:

Read.confirm (

ConnectID.

Ap plica tionlD.

ModulelD.

ObjectID.

Data

• 6.3.5 Служба Write

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

В таблице 8 представлены простые запросы, поддерживаемые Write-SAP. В таблице 9 описаны параметры простых запросов.

Таблица 8 — Простые запросы, поддерживаемые службой Write

Таблица 9 — Параметры простых запросов для службы Wnte

• 6.3.5.1 Write.request

Параметры данного простого запроса: Write.request (

SourceAddress.

DestinationAddress.

Mode.

ConnectID.

ApplicationlD.

ModulelD. Objects, Length. Data

}

• 6.3.5.2 Write.indication

Параметры данного простого запроса:

Write.indication (

SourceAddress, DestinationAddress. Mode.

Connects,

Applications, ModulelD. ObjectlD. Length. Data

}

• 6.3.5.3 Write.response

Параметры данного простого запроса:

Write.response (

SourceAddress.

DestinationAddress.

Mode.

ConnectID.

Applications.

ModulelD. Status }

• 6.3.5.4 Write.confirm

Параметры данного простого запроса:

Write.confirm {

SourceAddress.

ConnectID.

Applications, ModulelD. Status

}

• 6.3.6 Служба StartTest

Данная служба является подтвержденной. ТМ может использовать службу для запуска тестового задания. В таблице 10 представлены простые запросы, поддерживаемые StartTest-SAP. В таблице 11 описаны параметры простых запросов.

Таблица 10 — Простые запросы, поддерживаемые службой StartTest

Таблица 11 — Параметры простых запросов для службы StartTest

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

• 6.3.6.1 StartTest.r&quest

Параметры данного простого запроса:

StartTest.requestf

SourceAddress.

DestinationAddress, ConnectID.

Source Application,

DestinationApplication

)

• 6.3.6.2 StartTest.indication

Параметры данного простого запроса:

StartTest.indication{

DestinationAddress, ConnectID.

Source Application

• 6.3.6.3 StartTest.response

Параметры данного простого запроса:

StartTest.response{

SourceAddress.

DestinationAddress.

ConnectID.

SourceApplication.

Destination Appl i cation, Status

}

• 6.3.6.4 StarfTestconfirm

Параметры данного простого запроса:

StartTest.confirm{

Status

}

• 6.3.7 Служба StopTest

В таблице 12 представлены простые запросы, поддерживаемые StopTest-SAP, В таблице 13 описаны параметре! простых запросов.

Таблица 12 — Простыв запросы, поддерживаемые службой StopTest

Таблица 13 — Параметры простых запросов для службы StopTesl

• 6.3.7.1 StopTest.request

Параметры данного простого запроса:

StopTest.request{

SourceAddress,

DestinationAddress, ConnectID.

SourceApplication.

DestinationAppiication

}

• 6.3.7.2 StopTestindication

Параметры данного простого запроса:

StopTest.indication{

SourceAddress, ConnectID.

SourceApplication.

DestinationAppiication

}

• 6.3.7.3 StopTest.response

Параметры данного простого запроса:

StopTest.response{

SourceAddress.

DestinationAddress.

ConnectID.

SourceApplication, DestinationAppiication. Status

}

• 6.3.7.4 StopTest.confirm

Параметры данного простого запроса:

StopTest.confirmf Status

}

• 6.3.8 Служба StartDownAndUploadlng

Данная служба является подтвержденной. 8 таблице 14 представлены простые запросы, поддерживаемые StartDownAndUploading-SAP. 8 таблице 15 описаны параметры простых запросов.

Таблица 14 — Простые запросы, поддерживаемые службой StartDownAndUploading

Таблица 15 — Параметры простых запросов для службы StartDownAndUploading

• 6.3.8.1 StartDownAndUploading.request Параметры данного простого запроса: StartDownAndUptoadmg.request{

SourceAddress.

DestinationAddress, ConnectID.

SourceApplication,

DestinationApplication,

ArealD.

MaxSize.

Length

}

• 6.3.8.2 StartDownAndUploading.indication Параметры данного простого запроса: StartDownAndUptoading.indicat>on{

SourceAddress,

ConnectID.

SourceApplication.

ArealD

MaxSize

Length

• 6.3.8.3 StartDownAndUploading.response Параметры данного простого запроса: StartDownAndUploading.response{

SourceAddress.

DestinationAddress, ConnectID.

SourceApplication.

DestinationApplication.

ArealD.

Status

}

• 6.3.8.4 StartDownAndUploading.confirm Параметры данного простого запроса:

Start DownAndUploading.ccnfirm{ Status

}

• 6.3.9 Служба StopDownAndUploading

Данная служба является подтвержденной. 8 таблице 16 представлены простые запросы, поддерживаемые StopDownAndUploading-SAP. В таблице 17 описаны параметры простых запросов.

Таблица 16 — Простые запросы, поддерживаемые службой StopDownAndUploading

Таблица 17 — Параметры простых запросов для службы StopDownAndUploading

• 6.3.9.1 StopDownAndUploading.request Параметры данного простого запроса: StartDownAndUploading.requestf

SourceAddress.

DestinationAddress, ConnectID.

SourceAppti cation.

DestinationApplication. ArealD

}

• 6.3.9.2 StopDownAndUploading.indication Параметры данного простого запроса: StartDownAndUploading.indicationf

SourceAddress.

ConnectID.

SourceApplication, ArealD

}

• 6.3.9.3 StopDownAndUploading.response Параметры данного простого запроса: StartDownAndUploading.responsef

SourceAddress.

DestinationAddress.

ConnectID, SourceApplication. DestinationApplication. ArealD.

Status }

• 6.3.9.4 StopDownAndllptoading.confirm

Параметры данного простого запроса:

StartDownAndllptoading.confirmf

Status

}

• 6.3.10 Служба Datallploading

В таблице 18 представлены простые запросы, поддерживаемые DataUploading-SAP. В таблице 19 описаны параметры простых запросов.

Таблица 18 — Простыв запросы, поддерживаемые службой Datallploading

Таблица 19 — Параметры простых запросов для службы Datallploading

• 8.3.10.1 Datallploading.request Параметры данного простого запроса: Datallpbadirvg.indication {

SourceAddress. DestinationAddress. SourceApplication.

DestinationApplication, Connect! D.

ArealD, SquencelD. IsFinshed, currentLength. data

}

• 6.3.10.2 DataUploading.indication

Параметры данного простого запроса:

DataUploading.indication (

SourceAddress.

SourceApptication.

ConnectlD.

ArealD.

SquencelD. IsFinshed, currentLength. data

}

• 6.3.10.3 DataUploading.response

Параметры данного простого запроса:

DataUploading. response { ConnectlD. ArealD. status

}

• 6.3.10.4 DataUploading.confirm

Параметры данного простого запроса:

DataUploading.confirm { status

}

• 6.3.11 Служба DataDownloading

Данная служба является подтвержденной. 8 таблице 20 представлены простые запросы, поддерживаемые DalaDownloading-SAP. 8 таблице 21 описаны параметры простых запросов.

Таблица 20 — Простые запросы, поддерживаемые службой DataDownloading

Таблица 21 — Параметры простых запросов для службы DataDownloading

• 6.3.11.1 DataDownloading. request

Параметры данного простого запроса:

DataDownloading.request (

SourceAddress.

DestinationAddress.

SourceApplication.

DestinationApplication, ConnectlD.

ArealD.

SquencelD,

IsFinshed,

currentLength, Data

• 6.3.11.2 DataDownloading.tndication

Параметры данного простого запроса:

DataDownloading.indication {

SourceAddress.

SourceApplication.

ConnectlD.

ArealD.

SquencelD,

IsFinshed,

currentLength.

Data

• 6.3.11.3 DataDownloadiog.response

Параметры данного простого запроса:

DataDownloading.response {

ConnectlD.

ArealD.

Status

}

• 6.3.11.4 DataDownloading.confirm

Параметры данного простого запроса:

DataDownloading.confirm {

Status

• 6.3.12 Служба ExecuteTesting

Данная служба является подтвержденной. В таблице 22 представлены простые запросы, поодержиааемые ExecuteTesting-SAP. В таблице 23 описаны параметры простых запросов.

Таблица 22 — Простые запросы, поддерживаемые службой ExecuteTesting

Таблица 23 — Параметры простых запросов для службы ExecuteTesting

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

• 6.3.12.1 ExecuteTestiog.request Параметры данного простого запроса: ExecuteTesting.request (

SourceAddress. DestinationAddress. SourceApplication. DestinationApplication, ConnectlD. ModulelD. TestType. TestClass. TestSuitID. TestCaselD. Length. TestData

}

• 6.3.12.2 ExecuteTesting.indication Параметры данного простого запроса: ExecuteTesting.indication (

SourceAddress. SourceApplication, DestinationAppiicabon. ConnectlD. ModulelD. TestType. TestClass. TestSuitID. TestCaselD. Length. TestData

}

• 6.3.12.3 ExecuteTesting.response Параметры данного простого запроса: ExecuteTesting.response { SourceAddress. DestinabonAddress, SourceAppiicatron. DestinationApplication. ConnecttD, ModuleiD. TestType. TestClass. TestSurtID. TestCaselD.

Length, TestData. Status

• 6.3.12.4 ExecuteTesting.confirm

Параметры данного простого запроса: ExecuteTesting.confirm (

ModuleiD, TestSuitID, TestCaselD, Length, TestData. Status }

• 6.4 Службы управления тестированием

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

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

Таблица 24 —Службы управления и наименования SAPs

• 6.4.2 Служба Associate

Данная служба является подтвержденной и используется для создания нового соединения между отправителем и получателем. В таблице 25 представлены простые запросы, поддерживаемые Associate-SAP. В таблице 26 описаны параметры простых запросов.

Таблица 25 — Простые запросы, поддерживаемые службой Associate

Таблица 26 — Параметры простых запросов для службы Associate

• 6.4.2.1 Associate.request

Данный простой запрос запрашивает подписку на событие на уровне приложения. Параметры данного простого запроса:

As$odate.request{

SourceAddress.

DestinationAddress.

SourcePort.

DestinationPort.

SourceApplication.

DestinationApplication.

ConnectID.

Communication Mode

}

• 6.4.2.2 Associate.indication

Параметры данного простого запроса:

Assodate.indicatk>n{

SourceAddress.

SourcePort.

SourceApplication.

DestinationApplication.

ConnectID.

CommunicationMode

}

• 6.4.2.3 Associate.response

Параметры данного простого запроса:

Associate .response!

SourceAddress.

DestinationAddress.

SourcePort.

DestinationPort.

SourceApplication.

DestinationApplication.

ConnectID.

Common ication Mode.

Status.

Detail }

• 6.4.2.4 Associate.confirm

Параметры данного простого запроса:

Associate.confirm{

Source Application.

DestinationApplication.

ConnectlD.

CommunicationMode,

Status.

Detail

}

• 6.4.3 Служба Abort

В таблице 27 представлены простые запросы, поддерживаемые Abort-SAP. В таблице 28 описаны параметры простых запросов.

Таблица 27 — Простые запросы, поддерживаемые службой Abort

Таблица 26 — Параметры простых запросов для службы Abort

• 6.4.3.1 Abort.request

Параметры данного простого запроса: Abort.request{

SourceAddress.

DestinationAddress, SourcePort, DestinationPort. ConnectlD. Status. Detail

}

• 6.4.3.2 Abort.indication

Параметры данного простого запроса: Abort.indication{

SourceAddress, DestinationAddress.

SourcePort.

DestinationPort.

ConnectID.

Status.

Detail }

• 6.4.4 Служба AddressAllocation

8 таблице 29 представлены простые запросы, поддерживаемые AddressAlk>cation-SAP. В таблице 30 описаны параметры простых запросов.

Таблица 29 — Простые запросы, поддерживаемые службой AddressAJIocabon

Таблица 30 — Параметры простых запросов для службы AdckessAltocabon

• 6.4.4.1 AddressAllocation.request

Параметры данного простого запроса: AddressABocation.request{

SourceAddress.

DestinationAddress. ConnectID.

newAddress

}

• 6.4.4.2 AddressAliocation.indication

Параметры данного простого запроса:

AddressAJIocation.indication{

SourceAddress, DestinationAddress, ConnectID. newAddress

}

• 6.4.4.3 AddressAllocation.response

Параметры данного простого запроса:

AddressAllocation.responsef

SourceAddress. DestinationAddress. ConnectID.

Status

}

• 6.4.4.4 AddressAllocation.confirm

Параметры данного простого запроса:

AddressABocation.confirmf Status

}

6.4.5 Служба Sync

В таблице 31 представлены простые запросы, поддерживаемые Sync-SAP. В таблице 32 описаны параметры простых запросов.

Таблица 31 — Простые запросы, поддерживаемые службой Sync-SAP

Таблица 32 — Параметры простых запросов для службы Sync-SAP

• 6.4.5.1 Sync.request

Параметры данного простого запроса:

Sync.request (

SourceAddress.

SequencelD.

TimeStamp

}

• 6.4.5.2 Sync.indication

Параметры данного простого запроса:

Sync.indication {

SequencelD.

TimeStamp

6.4.6 Служба Devicestatus

В таблице 33 представлены простые запросы, поддерживаемые ME-SET-SAP. В таблице 34 описаны параметры простых запросов.

Таблица 33 — Простыв запросы, поддерживаемые службой DeviceStatus-SAP

Таблица 34 — Параметры простых запросов для службы DeviceStatus-SAP

• 6.4.6.1 DeviceStatus.request Параметры данного простого запроса: Devicestatus, requestj

SourceAddress. PhysicalStatus.

Applicationstatus. Modulestatus. TestStatus.

}

• 6.4.6.2 DeviceStatus.indication

Параметры данного простого запроса;

Devicestatus, indicationf SourceAddress. PhysicalStatus, Applicationstatus. Modulestatus. TestStatus.

}

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

Пример испытательной платформы для гибридных сенсорных сетей на основе IPv6

На рисунке А.1 показана испытательная платформа для гибридных сенсорных сетей на основе IPv6. В этой интегрированной платформе ТАР 1 используется для тестирования соответствия протокола маршрута 6LowFAN на основе 802.15.4. а ТАР2 для тестирования соответствия протокола IPv6 является конечным устройством на основе Ethernet.

Интерфейс Ethernet используется как TMR. так и двумя ТА. Унифицированные службы реализуются вебслужбами между ТМ и ТА. ТАР1 и ТАР2 в ТМ используются для управления ТА1 и ТА2 соответственно.

Стек протокола 6LowPAN в ТА1 основан на 802.15.4. ТА1 может использоваться для проверки поведения маршрутизации от DLTT1. ТА2 поддерживает стек протоколов IPv6 на основе 802.3, который напрямую взаимодействует с DUT2.

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

1MR

Рисунок А.1 — Испытательная платформа для гибридных сенсорных сетей на основе IPv6

Таблица АЛ —Тестирование на соответствие протокола 6L0WPAN на рисунке АЛ

Таблица А.2 — Тестирование на соответствие протокола IPv6 на рисунке АЛ

УДК 004.738:006.354

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

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

Сдано о набор 01.02.2021. Подписано о печать 17.02.2021. Формат 80 * 84Vg. Гарнитура Ариал.

Усл. печ. л. 4.18. Уч.-иад. л. 3.78.

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

Создано в единичном исполнении во . 117418 Москва. Нахимовский пр-т. д. 31. к. 2. www.gosbnfo.ru mfo@gosbnfo.nj