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

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

Розподіл фронтенду та бекенду в оборонних дашбордах

Домінуючий патерн у сучасній розробці дашбордів C2 — це односторінковий застосунок (SPA) на React або Vue, що споживає дані від набору мікросервісів бекенду через WebSocket-з'єднання для живих даних і REST для конфігурації та історичних запитів. Цей поділ забезпечує чіткий розподіл обов'язків: фронтенд відповідає за відображення стану, бекенд — за підтримку авторитетного стану та трансляцію дельт.

Бекенд мікросервісів зазвичай складається щонайменше з чотирьох сервісів у мінімальному розгортанні: сервіс треків (підтримує живу базу даних об'єктів), сервіс обміну повідомленнями (обробляє вхідні CoT та NFFI), сервіс оповіщень (оцінює правила та публікує сповіщення) та сервіс автентифікації (перевіряє JWT-токени та забезпечує виконання політик RBAC). Кожен сервіс контейнеризований — зазвичай Docker на Kubernetes для штабних розгортань або Docker Compose на захищеному сервері для передових позицій.

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

Прийом даних у реальному часі: WebSocket проти опитування

Для оновлень треків WebSocket — єдиний прийнятний варіант при тактичних вимогах до затримки. HTTP-опитування з 5-секундним інтервалом вносить середню затримку 2,5 секунди плюс час обробки сервером, що неприйнятно для повітряних треків, де застосовується поріг застарілості 10 секунд. WebSocket-з'єднання, що правильно керуються, забезпечують затримку менше 200 мс по локальній мережі та менше 500 мс через тактичний радіоканал.

Стандартний патерн реалізації — шлюз WebSocket з розгалуженням. Сервіс треків бекенду публікує дельти треків (не повний стан) у внутрішню шину повідомлень — зазвичай Redis Pub/Sub або NATS JetStream. Шлюз WebSocket підписується на шину, підтримує пул з'єднань автентифікованих браузерних сесій та розгалужує відповідні події до кожної сесії на основі ролі сесії та фільтра зони інтересів.

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

Технології відображення карт

Шар карти — найбільш візуально критичний компонент дашборду C2 і той, де вибір технології має найсуттєвіші наслідки. Три варіанти домінують у розробці оборонних C2: Mapbox GL JS, Cesium.js та власний WebGL-рендеринг поверх OpenLayers або Leaflet.

Mapbox GL JS — найпоширеніший варіант для 2D-дашбордів оперативної картини. Він відображає векторні тайли за допомогою WebGL, підтримує спеціальне впорядкування шарів та ефективно керує динамічним стилізуванням. Критично для розгортань у закритих мережах: Mapbox GL JS може бути повністю розгорнутий локально — обслуговуйте власний набір векторних тайлів з TileServer-GL або MapTiler Server, і бібліотека не матиме зовнішніх мережевих залежностей. Основне обмеження — лише 2D-рендеринг.

Cesium.js — стандарт для 3D-відображення земної поверхні. Підтримує еліпсоїдний режим глобуса, точний 3D-рельєф та динамічну за часом візуалізацію — траєкторії треків можуть відображатися як сліди на глобусі з точним відтворенням часу. Вартість продуктивності реальна: Cesium потребує дискретного GPU та сучасного CPU для плавного відображення при великій кількості треків.

Власні тайл-сервери для закритих мереж є вимогою в більшості національних оборонних програм. Середовище закритої мережі забороняє будь-які зовнішні виклики даних, що означає: всі фонові зображення, дані рельєфу та векторні картографічні дані мають обслуговуватися зсередини мережевого периметра. MapTiler Server Enterprise та TileServer-GL — найпоширеніші варіанти. Обидва підтримують MBTiles та можуть обслуговувати як растрові, так і векторні тайли.

Рольовий контроль доступу для рівнів командування

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

Стандартна реалізація використовує JWT-токени з вбудованими заявками, які кодують як роль користувача, так і його рівень доступу. API бекенду забезпечує доступ на рівні ресурсів. Фронтенд використовує ті ж самі заявки для умовного відображення елементів інтерфейсу — кнопка «Вогнева місія» не відображається для користувачів без ролі FIRE_CONTROL, а не просто вимкнена.

Продуктивність при масштабі: 10 000+ одночасних треків

Масштабованість кількості треків — найбільш недооцінена проблема при розробці дашбордів C2. Система рівня бригади в умовах високої інтенсивності може мати 500–2000 одночасних треків. Система театрального рівня, що відстежує повітряні, наземні, морські та космічні об'єкти одночасно, може перевищувати 50 000.

Ключове архітектурне рішення — чи відображати треки як DOM-елементи, SVG, Canvas 2D або WebGL. DOM та SVG не справляються понад приблизно 1000 елементів. Canvas 2D масштабується краще, але обмежений CPU. WebGL — єдиний варіант, що масштабується до 10 000+ треків при 60 FPS, використовуючи інстанційований рендеринг для малювання тисяч однакових символів одним викликом малювання.

При 10 000+ треках вузьким місцем стає обробка JavaScript вхідних подій WebSocket. Рішення — перенести управління станом треків у Web Worker: головний потік отримує необроблені фрейми WebSocket та передає їх (використовуючи transferable ArrayBuffer об'єкти) до воркера, який обробляє оновлення та повертає оновлений буфер позицій до головного потоку для завантаження на GPU.

Архітектурний принцип: Розділяйте шляхи читання від шляхів запису на рівні API. Читання треків є частим і чутливим до затримки; записи треків — нечастими та чутливими до коректності. Вони мають різні інфраструктурні вимоги і не повинні ділити один рівень сервісу.

Архітектура логіки оповіщень

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

Правила зберігаються як структуровані JSON-документи політик: умова (просторова — трек входить до визначеного полігону; атрибутна — швидкість треку перевищує поріг; часова — трек не оновлювався протягом N секунд) та дія (push WebSocket-сповіщення, створення запису оповіщення, тригер зовнішньої інтеграції). Рушій правил оцінює просторові умови за допомогою просторового індексу (R-tree є стандартом) для перевірок перетину полігонів O(log n).