Радиопередача, разобранная запись показаний счётчика и подтверждение приложения — это разные результаты. Сун, Ван и Ян описывают прототип газового счётчика NB-IoT с сообщением фиксированной длины, проверками отправки и приёма и тестовым интерфейсом сервера. В данной статье используется опубликованная 68-байтовая структура и описанный поток программы, чтобы объяснить, как покупатель может различать эти результаты. Таблица длин полей сохраняет значения авторов без воспроизведения идентификаторов устройств или сетевых адресов. Успешный обмен данными прототипа демонстрирует функции, показанные в этом примере. Приёмка на месте по-прежнему требует случаев отказа, повторяемости и чёткого определения ожидаемого ответа.

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

Сун, Ван и Ян описывают прототип со встроенным контроллером, модулем связи BC95 и серверным тестовым интерфейсом [1]. В этом обзоре последовательно рассматриваются архитектура, определение сообщений, поток программы и результат тестирования. В обзоре ставится вопрос о том, какие доказательства полной транзакции предоставляет статья и что должен показать приёмочный тест, когда одна часть обмена завершается неудачей.

Рисунок 1. Уровни восприятия, сети и приложений прототипа авторов. Song, Wang and Yang [1], оригинальный рисунок 1 (печатная версия, с. 114). Независимая английская функциональная перерисовка опубликованной диаграммы.

Рисунок 2. Блочная организация аппаратного обеспечения измерителя авторов. Song, Wang and Yang [1], оригинальный рисунок 2 (печатная версия, с. 114). Независимая английская функциональная перерисовка опубликованной диаграммы.

Рисунок 3. Два пути регулятора, значения развязки и сигнал разрешения 3,9 В. Song, Wang and Yang [1], оригинальный рисунок 3 (печатная версия, с. 114). Английская функциональная перерисовка. Номиналы компонентов взяты из опубликованной схемы. Это не попиновый монтажный чертёж.

Рисунок 4. Привод двигателя постоянного тока, состояния переключения и дискретная обратная связь по клапану. Song, Wang and Yang [1], оригинальный рисунок 4 (печатная версия, с. 114). Английская функциональная перерисовка опубликованной схемы управления и трёх рабочих состояний в разделе 2.3. Схема подключения компонентов не показана.

Рисунок 5. Схемы питания, радиомодуля, SIM и UART BC95. Song, Wang and Yang [1], оригинальный рисунок 5 (печатная версия, с. 115). Английская функциональная перерисовка с именами сигналов и значениями, перенесёнными из источника. Опущены детали физического подключения.

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

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

Рисунок 6. Организация низкоуровневого драйвера KL36. Song, Wang and Yang [1], оригинальный рисунок 6 (печатная стр. 115). Независимая английская функциональная перерисовка опубликованной диаграммы.

Рисунок 7. Поток связи BC95 с сохранением отдельных решений о повторных попытках для проверок соединения и передачи сообщений. Song, Wang and Yang [1], оригинальный рисунок 7 (печатная версия, с. 115). Независимая английская функциональная перерисовка опубликованной диаграммы.

Рисунок 8. Основные решения программы, триггеры событий и вывод. Song, Wang and Yang [1], оригинальный рисунок 8 (печатная версия, с. 115). Независимая английская функциональная перерисовка опубликованной диаграммы.

Рисунок. Иллюстрация пропорциональной длины полей на основе Song, Wang and Yang [1], раздел 3.2. Значения полей не воспроизводятся.

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

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

Рисунок 9. Интерфейс проверки прототипа. Song, Wang and Yang [1], оригинальный рисунок 9 (печатная версия, стр. 116). Обезличенный английский каркас на основе публикации. Исходные значения экрана, идентификаторы и байты сообщений опущены.

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

Полезный приёмочный тест может присвоить каждому attempted-отчёту прослеживаемую идентичность в рамках тестовой записи. Затем журнал может отдельно показывать отправку, получение, разбор, хранение и подтверждение. Корректный кадр проверяет обычный путь. Кадр неверной длины проверяет отклонение на парсере. Повторный корректный кадр проверяет, может ли приложение выявлять дубликаты. Задержка ответа проверяет, что записывает устройство и как оно возвращается в своё предполагаемое рабочее состояние. Это предлагаемые тестовые случаи, а не эксперименты, о которых сообщают авторы.

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

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

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

Имена полей и количество байтов взяты из цитируемого прототипа. Слово «верификация» соответствует имени поля в источнике. Никакие примеры идентификаторов, персональные данные или сетевые адреса из интерфейса не воспроизводятся.

[1] Song, H., Wang, Y., and Yang, F. (2019). «基于窄带物联网智能燃气表系统设计与实现» [Проектирование и реализация системы интеллектуального газового счётчика на основе NB-IoT]. 传感器与微系统, 38(3), стр. 113–116. Разделы 1–4 и рисунки 1–9. Схемы показывают соответствующие функциональные пути. Тестовый интерфейс был перерисован с опущенными идентификаторами и данными полезной нагрузки. https://doi.org/10.13873/J.1000-9787(2019)03-0113-04

Источник изображения: Song, Wang and Yang (2019), раздел 3.2, печатная стр. 115. Оригинальная визуализация только размеров полей. https://doi.org/10.13873/J.1000-9787(2019)03-0113-04

Титульное фото: Министерство энергетики США, архив Оук-Ридж. Фотограф Комиссии по атомной энергии Эд Уэсткотт со своим киносъёмочным оборудованием в Оук-Ридж. Работа правительства США, общественное достояние согласно исходной записи. Редакционная обрезка фото и макет заголовка. https://commons.wikimedia.org/wiki/File:Ed_Westcott_with_film_making_Equipment_Oak_Ridge_1960.jpg