Автономная регистрация данных и Store-and-Forward в промышленных IoT-шлюзах

Быстрый ответ

Почему офлайн-возможности важны

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

Локальная регистрация данных и автономный кэш

Где хранятся данные

Различные классы шлюзов используют внутреннюю флэш-память, внешние TF-карты, USB-накопители или встроенные базы данных. Не предполагайте, что спецификация памяти заголовка равна пространству, доступному для исторических данных; операционная система и разбиение на разделы уменьшают полезную емкость. Аналогично, шлюз с поддержкой USB может использовать USB-накопитель для резервного копирования, а не для непрерывной потоковой передачи в реальном времени.

Файлы базы данных против файлов CSV

Некоторые прошивки хранят записи в локальном файле базы данных в стиле SQLite. Это эффективно для шлюза, но для экспорта CSV может потребоваться инструмент базы данных. Другие продукты для регистрации данных или версии встроенного ПО могут напрямую экспортировать CSV. При закупках «поддержка USB-накопителя» и «USB-накопитель напрямую экспортирует CSV» следует рассматривать как два разных требования.

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

Как оценить продолжительность хранения

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

Примерная формула планирования: продолжительность хранения = используемые байты ÷ байты на запись ÷ записи в день. Записей в день = 86 400 секунд ÷ интервал выборки в секундах. Добавьте запас для индексов, метаданных и накладных расходов файловой системы.

Пример: 10-минутная и 15-минутная выборка

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

Как должна работать технология Store-and-Forward

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

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

Поведение MQTT и HTTP в автономном режиме может отличаться

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

Автономные исследования и полевые журналы

Некоторым проектам не требуется внешняя сеть. Научно-исследовательский институт может подключить датчики к регистратору данных, оставить станцию ​​работающей на несколько недель и периодически получать данные с помощью USB или TF-накопителя. В этом случае приоритет выбора меняется с производительности 4G на надежность локального хранилища, точность временных меток, мощность датчиков, формат данных и простоту экспорта.

Вопросы для включения в запрос предложений

1. Какой носитель используется для обычной истории и неотправленного кеша?
2. Какой объем доступной памяти доступен приложению?
3. Ограничено ли хранение днями, записями, байтами или процентом хранилища?
4. Какой формат файла/базы данных используется локально?
5. Может ли пользователь экспортировать CSV напрямую или требуется преобразование?
6. Шлюз автоматически переподключается после сбоя 4G или сервера?
7. Кешированные записи автоматически пересылаются после восстановления?
8. Каков порядок повторной отправки и как обрабатываются повторяющиеся записи?
9. Может ли шлюз продолжать выборку во время повторной отправки журнала?
10. Может ли клиент установить собственную TF-карту или USB-накопитель и какой формат требуется?

Приемочные испытания на надежность в автономном режиме

1. Запустите систему онлайн и подтвердите нормальные временные метки и загрузку.
2. Отключите восходящий канал сотовой связи/сети, оставив датчики и шлюз включенными.
3. Позвольте нескольким циклам отбора проб накопиться локально.
4. Восстановите соединение и проверьте автоматическое переподключение.
5. Сравните базу данных сервера с локальными метками времени, чтобы убедиться, что отсутствующий период был восстановлен.
6. Выключите и снова включите шлюз во время сбоя, если требуется устойчивость к потере питания.
7. Экспортируйте локальную историю, чтобы проверить доступ для обслуживания и формат файла.
8. Задокументируйте встроенное ПО, носитель данных и протестированное поведение хранения и повторной отправки при передаче.

FAQ

Вопрос 1. Что такое Store-and-Forward в IoT-шлюзе?

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

В2. Является ли локальная регистрация данных такой же, как и автономный кэш?

А2. Нет. Локальное ведение журнала представляет собой непрерывную историю; автономный кэш специально защищает записи, которые не удалось загрузить.

Вопрос 3. Может ли IoT-шлюз хранить данные без доступа в Интернет?

А3. Да, если выбранная модель обеспечивает локальную запись на Flash, TF-карту, USB или другой носитель.

Вопрос 4. Можно ли использовать USB для вывода данных в реальном времени?

А4. Не обязательно. На многих шлюзах USB предназначен для резервного копирования или ручного экспорта исторических данных, а не для непрерывного потока в реальном времени.

Вопрос 5. Всегда ли локальные данные будут в формате CSV?

А5. Нет. Некоторые прошивки используют файл базы данных и требуют последующего экспорта в CSV. Укажите необходимый формат в проекте.

Вопрос 6. Как рассчитать, сколько дней шлюз может хранить данные?

А6. Измерьте реальный размер записи, рассчитайте количество записей в день на основе интервала выборки, затем разделите полезное хранилище на ежедневный объем данных и включите запас накладных расходов.

Вопрос 7. Будут ли кэшированные данные автоматически отправлены после восстановления сети?

А7. Когда функция автономного кэширования включена и поддерживается настроенным протоколом, шлюз может повторно подключиться и повторно передать сохраненные записи.

Вопрос 8. Должен ли я тестировать сбой сервера и сбой 4G отдельно?

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