Промислові мережі IoT: зберігання та пересилання поза мобільним покриттям

Почніть з інформації, яка має вижити

Операції з обмеженим покриттям рідко потребують постійного широкосмугового з’єднання всюди. Їм потрібна вибрана інформація, щоб надходити передбачувано: екстрені сповіщення, позиція, статус команди, короткі повідомлення та стан мережі. Визначення пріоритету повідомлень, терміну дії та правил підтвердження важливіше, ніж максимізація швидкості передачі даних заголовків.

Розділіть ролі вузла, ретранслятора та шлюзу

Польовий вузол повинен залишатися простим і енергоефективним. Реле, що розгортається, розширює покриття та передає повідомлення у разі тимчасових збоїв. Шлюз приєднується до локальної мережі для управління програмним забезпеченням або доступним транспортним зв’язком. Розподіл цих ролей дозволяє кожному пристрою оптимізувати енергію, розміщення антени, сховище та інтерфейс користувача для своєї роботи.

Store-and-forward — це операційна політика

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

План рельєфу та погіршених зв'язків

Бюджети зв’язку, висота антени та розміщення реле повинні бути оцінені відповідно до місцевості та обмежень щодо встановлення. Такі показники працездатності мережі, як частота повторних спроб, глибина черги та якість сусідів, допомагають операторам зрозуміти, чи справний шлях повідомлення до того, як відбудеться термінова подія.

Розумне землеробство та дистанційний моніторинг енергії

Інтелектуальна сільськогосподарська установка може потребувати періодичного спостереження за ґрунтом або навколишнім середовищем, негайних сповіщень обладнання та періодичних діагностичних завантажень. Віддалений енергетичний сайт може мати подібні класи трафіку з різними вимогами до утримання та потужності. Визначте інформацію, яка залишається корисною після затримки, і інформацію, термін дії якої швидко закінчується.

Рішення про локальне керування не повинно залежати від недоступного підключення до хмари. Відокремте телеметрію від шляху керування та визначте поведінку обладнання під час збою. Відповідна відповідь залежить від програми та має бути погоджена та перевірена в рамках проекту.

Розмір локального сховища навколо збою

Оцініть збережений обсяг пам’яті на основі розміру повідомлення, частоти надсилання повідомлень і найдовшого збою, який необхідно охопити, а потім включіть накладні витрати на індексування та робочий запас. Визначте, що відбувається, коли сховище заповнюється: відкидайте найстаріші рутинні зразки, об’єднуйте їх або резервуйте ємність для пріоритетних подій. Не залишайте це рішення випадковим збоєм файлової системи.

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

Перевірте повну польову мережу

Виміряйте доступність зв’язку на фактичній висоті монтажу та місці встановлення. Оцінка робочого циклу радіозв’язку разом із записами датчиків, обробкою та зберіганням; сама по собі малопотужна радіостанція не гарантує довговічність вузла. Включіть антену, корпус і умови навколишнього середовища в пілотний проєкт.

Перевірте заплановане відключення, повну чергу, перезапуск під час передачі та відновлення під час спалаху трафіку в черзі. Прийняття має включати вік повідомлення, втрату, дублікати та використання енергії. Ці вимірювання дозволяють оцінити розгортання Інтернету речей за межами того, чи може інформаційна панель відобразити один успішний зразок.

Досліджуйте програми підключеного датчика