Архітектура військової IoT-мережі сенсорів для оборонних операцій

Поле бою стає інструментованим у масштабах, які ще десять років тому здавалися б немислимими. Безпілотні наземні сенсори, закопані вздовж ймовірних маршрутів підходу. Носимі пристрої на кожному солдаті, що передають частоту серцевих скорочень, GPS-позицію та стан спорядження. Шини CAN транспортних засобів, що транслюють діагностику двигуна, залишок пального та боєкомплект. Системи виявлення периметра навколо передових операційних баз. Логістичні трекери на кожному піддоні в ланцюгу постачання. Обсяг даних — колосальний, і майже всі вони передаються через оспорювані радіоканали з обмеженою пропускною здатністю, нерегулярною доступністю та противником, який активно намагається їх заглушити або зламати.

Комерційна IoT-архітектура не була розрахована на таке середовище. AWS IoT Core, Azure IoT Hub та подібні платформи передбачають надійний хмарний зв'язок, керовану кількість пристроїв і модель загроз, що обмежується периметральним міжмережевим екраном. Військові IoT-мережі сенсорів вимагають принципово іншої архітектури — такої, що переносить обробку ближче до сенсора, агресивно стискає та пріоритизує дані, захищає кожен пристрій на апаратному рівні та контрольовано деградує при повній втраті зв'язку. У цій статті описано, як її побудувати.

Таксономія сенсорів: охоплення військового IoT

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

Безпілотні наземні сенсори (БНС) — це замасковані пристрої на батарейному живленні, що виявляють і класифікують активність у фіксованій точці за допомогою акустичних, сейсмічних, пасивних інфрачервоних або магнітних датчиків. Зазвичай вони розгортаються в мешових мережах у зоні спостереження і повинні працювати від одного комплекту батарей днями або тижнями. Сирі швидкості передачі даних невисокі — сейсмічний сенсор генерує кілобайти на подію, а не мегабайти, — але оскільки в районі батальйону може бути розгорнуто сотні вузлів, сукупна швидкість прийому даних є суттєвою. БНС генерують рідкісний, подійно-керований вивід: коли нічого не відбувається — вони нічого не передають; коли виявляють сигнатуру транспортного засобу — надсилають компактний звіт класифікації.

Носимі сенсори солдата включають GPS-приймачі, біометричні монітори та датчики стану спорядження, інтегровані в бронежилети, шоломи та вантажне спорядження. Вони передають позицію з інтервалом 1–10 секунд, життєві показники — з інтервалом 30 секунд, а сповіщення про стан спорядження — за подією. Ключове обмеження: солдати мобільні та не можуть мати при собі супутниковий канал; їхні сенсори передають дані через меш «солдат — солдат», що тунелюється через найближчий шлюз транспортного засобу до серверної частини C2.

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

Системи виявлення периметра на стаціонарних об'єктах поєднують паркові сенсори, наземні радари, акустичні детектори та камери ЕО/ІЧ у багаторівневий масив виявлення. На відміну від БНС, вони живляться від зовнішньої мережі й можуть підтримувати вищі швидкості передачі даних. Складність інтеграції полягає в агрегуванні кількох технологій виявлення в єдину ціль: вібрація огорожі та тривога теплової камери, що виникли протягом трьох секунд в одному місці, мають породжувати одне сповіщення про прорив периметра, а не два окремих.

Логістичне відстеження застосовує IoT до ланцюга постачання: піддони, контейнери та транспортні засоби з паливом, боєприпасами, продовольством і запасними частинами. Температурні та ударні датчики на медикаментах і чутливому обладнанні забезпечують моніторинг стану. GPS-трекери передають позицію з грубим інтервалом — кожні 10–15 хвилин зазвичай достатньо для логістичного управління. Унікальна вимога тут — міждоменний потік даних: логістична інформація повинна надходити як до тактичного C2, так і до тилових систем управління ланцюгом постачання, що нерідко функціонують на окремих мережах з різними рівнями грифу.

Обмеження зв'язку: проєктування для оспорюваних каналів з обмеженою пропускною здатністю

Визначальне обмеження військового IoT — зв'язок не є ні надійним, ні безкоштовним. Тактичні радіоканали — КХ, ОВЧ, УВЧ, SATCOM або мешові хвильові форми — працюють у межах суворих бюджетів пропускної здатності, схильні до радіоглушіння та перешкод і можуть навмисно вимикатися (EMCON — контроль радіовипромінювання) для зменшення електронної сигнатури підрозділу.

Основоположний принцип — дані мають бути спроєктовані так, щоб витримати відключення зв'язку. Кожен вузол мережі повинен вміти автономно функціонувати протягом визначеного часу простою, буферизуючи події локально з порядковими номерами та мітками часу та відтворюючи їх у правильному порядку при відновленні зв'язку. Серверна частина C2 має вміти відновлювати цілісну картину треків із пачки буферизованих звітів, що надходять не в порядку відносно інших вузлів.

Розподіл пропускної здатності підпорядковується суворій ієрархії пріоритетів. Критичні тактичні сповіщення — виявлення БНС транспортного засобу на вузловому пункті, прорив периметра, біометрична тривога солдата про непрацездатність — мають передаватися негайно і мають пріоритет над будь-яким менш пріоритетним трафіком. Ці повідомлення невеликі: звіт про виявлення БНС зазвичай займає менше 200 байт. Рутинні оновлення позиції та стану утворюють другий рівень: передаються із заданими інтервалами, коли є доступна пропускна здатність, і відкидаються або затримуються при насиченні каналу. Господарські дані — телеметрія батареї, звіти про калібрування сенсорів, рядки версій програмного забезпечення — відкладаються до вікон масової передачі в періоди доброго зв'язку або навмисних адміністративних сесій.

Зі стрибкоподібною перебудовою частоти та інші хвильові форми з низькою ймовірністю перехоплення є стандартом для зв'язку мешів БНС. Ці хвильові форми стійкі до радіоглушіння ціною нижчої ефективної пропускної здатності; сенсорна мережа має бути спроєктована так, щоб функціонувати в цих межах. LoRa та LoRaWAN використовуються в середовищах з нижчою загрозою, де важливіші бюджет живлення та дальність зв'язку; вони забезпечують чудову дальність при низькій потужності, але пропускна здатність обмежена сотнями байт на секунду на канал.

Архітектура крайової обробки: що обчислювати безпосередньо на сенсорі

Крайова обробка — обчислення на сенсорі або поряд з ним, а не в хмарі — у військовому IoT є не оптимізацією, а вимогою. Бюджет пропускної здатності просто не може вмістити сирі потоки даних від сотень пристроїв одночасно.

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

По-друге, класифікація: присвоєння категорії виявленій події за допомогою легкої моделі, що виконується безпосередньо на пристрої. Сучасні процесори БНС здатні запускати невеликі класифікатори нейронних мереж для розрізнення транспортний засіб — особовий склад — хибна тривога. Оцінка достовірності класифікації передається разом із звітом про подію, дозволяючи рівню злиття відповідно зважувати її. Подія, класифікована з достовірністю 0,95 як гусеничний транспортний засіб, вимагає іншої реакції, ніж подія з достовірністю 0,60.

По-третє, стиснення та серіалізація: кодування звіту про подію в найбільш компактному форматі, сумісному з вимогами схеми серверної частини C2. Підходять Protobuf і FlatBuffers; JSON — ні. Закодований у Protobuf звіт про виявлення БНС може передати всі оперативно релевантні поля — UUID пристрою, мітку часу, тип сенсора, класифікацію, достовірність, GPS-фікс, рівень заряду батареї — менш ніж у 100 байтах. Еквівалентне представлення JSON у п'ять-десять разів більше без жодного функціонального виграшу.

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

Стиснення та пріоритизація даних через обмежені канали

Стиснення на рівні повідомлень необхідне, але недостатнє. Архітектура також повинна реалізовувати інтелектуальну пріоритизацію, яка гарантує пропуск критичного трафіку навіть при наближенні каналу до насичення.

Для позиційних даних — GPS-треки солдатів, позиції транспортних засобів — дельта-кодування дає значне стиснення. Замість передачі повної координати WGS84 при кожному циклі оновлення пристрій передає лише зміщення відносно попередньої зафіксованої позиції, масштабоване до необхідної точності. Солдат, що рухається кроком, долає приблизно 1,5 метра на секунду; кодування дельт позиції у 16-бітних цілих числах із сантиметровою роздільністю замість повних 64-бітних чисел IEEE з рухомою комою зменшує корисне навантаження позиції на 75%, зберігаючи точність краще метра при будь-якому розумному інтервалі оновлення.

Для даних хвильових форм сенсорів, що інколи мають передаватися — сирі акустичні фрагменти для криміналістичної реконструкції, мініатюри ЕО/ІЧ для перегляду людиною, — стандартне стиснення без втрат (LZ4 або Zstandard) забезпечує зниження в 2–4 рази на типовому виводі сенсорів із незначними витратами ЦП на рівнях потужності БНС. Стиснення з втратами прийнятне для мініатюр ЕО/ІЧ, призначених для перегляду людиною; воно неприйнятне для записів радіоелектронної розвідки, які можуть використовуватися для алгоритмічної класифікації.

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

Буферизація з пересиланням при відновленні зв'язку вимагає ретельного управління буфером. Буфери мають бути обмеженими: необмежений буфер, що накопичує години даних, при відновленні зв'язку затопить канал застарілими спостереженнями, витіснивши поточні тактичні дані. Правильне рішення застосовує мітки TTL до кожного буферизованого повідомлення. При відновленні зв'язку повідомлення із закінченим TTL відкидаються; відтворюються лише повідомлення в межах свого вікна дійсності. Критичні сповіщення мають довші TTL, ніж рутинні оновлення стану. Господарські дані можна повністю відкидати після граничного часу.

Архітектура злиття даних сенсорів: від сирих подій до треків цілей

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

Архітектура злиття для поля сенсорів військового IoT працює на двох рівнях. На рівні вузла пристрій-шлюз агрегує події від сенсорів свого кластера — як правило, у радіусі від 500 метрів до 1 кілометра — і застосовує часове стробування для групування подій, що ймовірно відносяться до однієї фізичної цілі. Події акустичних і сейсмічних сенсорів одного й того ж БНС, що виникли протягом 500 мілісекунд, майже напевно є одним і тим самим проходженням транспортного засобу; комбінування за Демпстером-Шафером об'єднує дві ймовірності класифікації в єдину зведену оцінку, що є більш достовірною, ніж будь-який окремий сенсор.

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

Мультимодальне злиття — поєднання акустичних, сейсмічних і оптичних виводів від однієї й тієї ж цілі — покращує як ймовірність виявлення, так і точність класифікації. Акустичні сенсори відзначаються дальністю, але чутливі до вітрового шуму і плутають типи транспортних засобів на відстані. Сейсмічні сенсори менш схильні до вітру, але вимагають близькості транспортного засобу. Оптичні сенсори забезпечують однозначне візуальне підтвердження, але вимагають прямої видимості та достатнього освітлення. Ціль, підтверджена двома або більше модальностями, заслуговує на інший символ відображення та рівень тривоги порівняно з ціллю, виявленою одним сенсором, — рівень злиття повинен зберігати та надавати цю інформацію про провенанс рівню C2. Докладний розгляд алгоритмів мультимодального злиття наведено у статті про архітектуру мультисенсорного злиття.

Архітектура безпеки: ідентичність пристроїв, шифрування транспортного рівня та оновлення OTA

Військові IoT-пристрої функціонують у середовищах, де фізичне захоплення є реалістичною загрозою. Противник, що відновив БНС, може спробувати витягти його облікові дані, відтворити його повідомлення для введення хибних треків цілей у картину C2 або використати його радіостанцію для виявлення інших пристроїв у меші. Архітектура безпеки повинна враховувати всі три вектори загроз.

Ідентичність пристрою на основі сертифікатів X.509. Кожен пристрій у мережі отримує унікальний сертифікат під час виробництва або передрозгортальної підготовки, виданий ієрархією центрів сертифікації програми. Приватний ключ генерується безпосередньо на пристрої і зберігається в захищеному від зломів елементі — апаратному модулі безпеки, Trusted Platform Module або еквівалентному захищеному елементі, — який обнулить ключ при виявленні злому. Common Name сертифіката кодує тип пристрою, серійний номер і контекст розгортання, дозволяючи службі прийому даних перевірити не лише дійсність сертифіката, а й що саме цей пристрій авторизований для передачі до цього конкретного сервера в цей момент часу. Пристрої із простроченими, відкликаними або нерозпізнаними сертифікатами відхиляються на транспортному рівні, до будь-якої обробки на рівні застосунку.

DTLS 1.3 для протоколів сенсорів на основі UDP. Більшість протоколів БНС і низькоенергетичних сенсорів використовують UDP, а не TCP — накладні витрати механізмів надійності та впорядкування TCP неприйнятні для обмежених радіоканалів. DTLS (Datagram Transport Layer Security) забезпечує ті самі криптографічні гарантії, що й TLS, але поверх UDP, з адаптаціями для втрати пакетів і їх переупорядкування. DTLS 1.3 скорочує рукостискання з двох обходів до одного (для нового з'єднання) або нуля (при відновленні сесії для перепідключених пристроїв), мінімізуючи вартість пропускної здатності при відновленні безпеки після відключення каналу. Шлюз підтримує кеш відновлення сесій, ключованих за відбитком сертифіката пристрою, що дозволяє перепідключеному БНС відновити сесію за один обхід.

Захист від повторного відтворення. Атаки відтворення — запис і повторна передача легітимного повідомлення про виявлення для формування хибної цілі — нейтралізуються монотонно зростаючими порядковими номерами, прив'язаними до сертифіката пристрою. Служба прийому даних підтримує вікно отримання для кожного пристрою і відхиляє повідомлення з порядковими номерами нижче нижньої межі вікна. Порядкові номери зберігаються в захищеному від зломів елементі для збереження при циклах живлення; пристрій, що втратив стан порядкових номерів, не може безпечно відновити передачу, доки не повторно автентифікується та не отримає новий порядковий номер від сервера.

Захищені OTA-оновлення мікропрограми. Мікропрограма сенсорів має оновлюватися в полі для усунення вразливостей і розширення можливостей. Пакет оновлення підписується приватним ключем підпису коду постачальника; пристрій перевіряє підпис відносно відкритого ключа, закріпленого в ROM завантажувача, перед застосуванням оновлення. Сам канал OTA використовує те саме захищене DTLS-з'єднання, що й оперативні дані. Часткове або пошкоджене оновлення виявляється шляхом перевірки хешу завантаженого пакету перед записом у флеш-пам'ять; пристрій відкочується до попередньої версії мікропрограми, а не завантажує пошкоджений образ. Пакети оновлень розповсюджуються через шлюзову меш під час адміністративних вікон, а не через оперативний канал, запобігаючи конкуренції трафіку оновлень із тактичними даними.

Інтеграція з C2: від треку сенсора до оперативної картини

Вихід конвеєра злиття сенсорів — потік треків цілей з позицією, швидкістю, ймовірністю класифікації та метаданими провенансу — має прийматися системою C2 у форматі, що не потребує додаткового перетворення. Два домінуючих формати повідомлень для інтеграції з оборонним C2 — CoT (Cursor on Target) та повідомлення J-серії Link 16.

CoT є практичним вибором для IoT-інтеграції в наземному домені. Він заснований на XML, широко підтримується клієнтами та серверним програмним забезпеченням сімейства ATAK та розширюваний через типізовані дочірні елементи detail. Трек цілі БНС природно відображається на подію CoT: елемент point несе злиту позицію та радіус невизначеності; елемент detail несе класифікацію, достовірність і поля бітової маски джерела як типізовані дочірні елементи. Модель життєвого циклу подій CoT — треки зі скінченним часом застарівання, що спливають і зникають з ЄОП якщо не оновлюються — точно відповідає моделі загасання достовірності рівня злиття.

Служба прийому даних, що отримує CoT від конвеєра злиття, має бути безстановим шлюзом: вона перевіряє формат повідомлення, перевіряє сертифікат джерела відносно списку авторизованих відправників, застосовує будь-яке необхідне маркування даних для грифу та релізності та публікує до шини повідомлень C2. Жодний стан треків не зберігається в самому шлюзі; стан живе у службі злиття та в базі даних треків сервера C2.

Наскрізна затримка від фізичної події до відображення на ЄОП має бути конструктивною вимогою, а не другорядним міркуванням. Для критичних тривог БНС ціль — менше п'яти секунд від виявлення сенсором до сповіщення оператора. Вимірюйте це в реалістичних мережевих умовах — включаючи змодельовані відключення каналу та пакетне відновлення зв'язку — і інструментуйте конвеєр на кожному етапі для виявлення місць накопичення затримки. На практиці домінуючими складовими є час обробки крайньої класифікації (як правило, менше секунди на сучасних процесорах БНС), черговість у шлюзі при насиченні каналу (змінна) та обробка оновлення треків на сервері C2 (як правило, менше 500 мілісекунд при добре структурованому конвеєрі злиття).