Побудова C2-системи з нуля, частина 3: спільна оперативна картина

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

Крок 1: фронтенд-стек

Для прикладу платформи, що проходить через серію, СОК — це браузерний застосунок. Вибір між нативним і веб-варіантом уже понад десятиліття вирішено на користь веб; залишковий нативний слід припадає на спеціалізовані handheld-платформи (екосистема ATAK — див. Розробка плагінів для ATAK), а не на дисплеї командних пунктів.

Захищений стек:

• React з TypeScript для оболонки застосунку. Зрілість екосистеми, доступність кадрів і дружня до акредитації інструментальна база роблять його безпечним вибором для платформи з 20-річним горизонтом. Vue — захищеним; Svelte поки не є вибором рівня закупівлі для оборонного сектору.
• Cesium для перегляду глобусу та 3D — рельєф, об'єми повітряного простору, супутникові траєкторії. З WebGL-прискоренням, зрілий, де-факто стандарт для геопросторового 3D в обороні.
• Mapbox GL або MapLibre для 2D-перегляду мапи. Векторні тайли для швидкості; растровий тайловий фолбек для офлайн-режиму. Компроміси і стелю продуктивності розкрито в Рендеринг мап у реальному часі для військового C2.
• Zustand або Redux Toolkit для стану. Обсяг потокових оновлень треків робить наївний React-стан непридатним; використовуйте store із референційно стабільними селекторами та порівняннями shallow-equal.
• Ant Design або Mantine для оточуючого UI — панелі, модалки, форми. Опирайтеся спокусі будувати кастомну дизайн-систему в першій ітерації; беріть зрілу бібліотеку та темізуйте її під оборонні конвенції.

Одне неочевидне рішення: тримайте СОК як single-page application, а не як багатосторінковий сайт. Оператори не навігують. Вони відкривають СОК один раз і користуються нею годинами. Перезавантаження сторінок — це неправильна абстракція; правильна — це види та панелі всередині єдиної оболонки.

Крок 2: військова символіка, зроблена правильно

Треки рендеряться як символи. Каталог символів регламентує MIL-STD-2525D (або еквівалентний варіант НАТО APP-6). Саморобна symbology — це червоний прапор для закупівлі та блокер сумісності: щойно платформа інтегрується з союзною системою, неузгоджені символи спричиняють негайний провал відповідності.

Використовуйте підтримувану бібліотеку. Open-source реалізація milsymbol — де-факто вибір для веб-СОК; вона видає стандартний набір символів як SVG або canvas-малюнки. Бібліотека опрацьовує афіліацію (друг, ворог, нейтрал, невідомий), маркери ешелону, ідентифікувальний текст і модифікатори, що перетворюють загальний символ піхоти на «1-й батальйон, механізований, в обороні».

Патерн інтеграції: рушій злиття видає треки з атрибутами ідентичності; СОК шукає відповідний MIL-STD-2525 SIDC (Symbol Identification Code) для цих атрибутів; бібліотека рендерить символ. Кешуйте відрендерені символи за SIDC; той самий символ повторно використовується тисячі разів у типовій оперативній картині.

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

Крок 3: оновлення в реальному часі через WebSocket

Завдання СОК — відображати сховище треків у близькому до реального часу. Polling не масштабується; WebSocket — це структурна відповідь. Архітектурний патерн:

Шлюз-сервіс тримає відкриті WebSocket-з'єднання до кожного браузера. Він підписаний на топіки рушія злиття tracks.updates і tracks.lifecycle. Коли надходить оновлення треку, шлюз обчислює фільтр для конкретного з'єднання (яка область, які ролі, які класифікації) та надсилає оновлення браузеру. Браузер застосовує оновлення до локального сховища стану; React перерендерює лише уражені символи.

Неочевидні інженерні деталі, що визначають, чи це працюватиме в масштабі:

Фільтрація відбувається на стороні сервера. Штовхати кожен трек у кожен браузер не працює — при 10 000 треках, що оновлюються кілька разів на хвилину, і канал, і браузер задихаються. Кожне з'єднання має фільтр підписки (межі viewport, шари на основі ролей, фільтр класифікації), і течуть лише оновлення, що збігаються з ним.

Часткові оновлення (deltas), а не повні заміни. Оновлення треку — це partial: позиція змінилася, стан lifecycle змінився, ідентичність уточнено. Браузер застосовує патч до локальної копії. Повні payload треку надсилаються лише на початкову підписку та при міграціях схеми.

Перепідключення з відновленням стану. WebSocket-з'єднання падають, особливо в тактичних мережах. Під час reconnect браузер обмінюється зі шлюзом останнім побаченим sequence-номером, і шлюз відтворює пропущені оновлення з шини. Без втрати стану, без повного перезавантаження.

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

Крок 4: фільтрація на основі ролей та класифікація

Не кожен оператор бачить кожен трек. СОК командира піхотного взводу не показує зон вогневого ураження ППО. Обліковий запис рівня NATO-RESTRICTED не бачить треків із класифікацією SECRET. Платформа примушує це у двох місцях: фільтр шлюзу (що надсилати) та політика-рушій (чи надсилати взагалі).

Рольовий фільтр — це конфігурація на користувача та сесію: які типи треків, які райони операцій, які шари відображення. Користувач може коригувати в межах своєї авторизації; система примушує верхню межу. Класифікаційний фільтр — не підлягає обговоренню: ефективна класифікація треку (обчислена при злитті, поширена на шлюз) має бути на рівні або нижче допуску користувача. Перехресні перевірки на рівні API та БД — ніколи лише в UI — це правило. Детальний патерн розкрито в Контроль доступу на основі ролей в оборонних C2-системах.

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

Крок 5: ергономіка оператора

СОК, що зазнає невдачі ергономічно, зазнає невдачі операційно. Дисципліна збирається з кількох не обговорюваних правил.

Індикація застарілих треків. Коли стан lifecycle треку — fading або lost, символ змінюється — зазвичай тьмяніший, можливо з обведенням, з індикатором віку. Оператори повинні з одного погляду бачити, яким трекам можна довіряти.

UI вирішення конфліктів. Коли два оператори одночасно редагують той самий трек чи задачу, платформа повинна підняти конфлікт, а не тихо перезаписати один бік. Last-writer-wins на рівні окремих атрибутів — це дефолт; явне узгодження — для атрибутів із високими ставками.

Дизайн «спочатку клавіатура». Тільки-мишачі UI провалюються у стресових операціях. Кожна поширена дія має клавіатурне скорочення; скорочення задокументовано всередині продукту і їх можна виявити.

Експлуатація з сенсором і в рукавичках для ruggedized-цілей. Та сама СОК працює в командних пунктах на робочих станціях і на захищених планшетах на висунутих бригадних позиціях. Розміри hit-цілей розраховані на рукавички; високо-контрастні режими — повноцінні. Ширший патерн — у Ruggedized UX для військових операторів.

Офлайн-робота. Розгортання на тактичному edge втрачають зв'язок. СОК повинна функціонувати з локального кешу, відтворювати чергу дій оператора при перепідключенні та чітко показувати, які дані застаріли. Архітектурний патерн — у Offline-first військові застосунки; офлайн-карти — у Офлайн-карти з MBTiles і PMTiles.

Крок 6: поза межами мапи — дашборди та панелі

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

Архітектурний поділ, що варто зберегти: вид мапи — це одна панель; дашборди та бічні панелі — інші панелі; вони ділять спільний стан виділення через центральний store. Додавання нового аналітичного інструмента — це нова панель, а не новий застосунок. Патерни архітектури дашбордів — у Архітектура C2-дашборда.

Крок 7: цільові показники продуктивності

Цілі СОК жорсткіші, ніж звучать:

• Початкове завантаження менше 3 секунд на ноутбуці тактичного edge з кешованими статичними ресурсами.
• Затримка оновлення треку менше 200 мс від emit зі шлюзу до видимого зрушення символу в браузері.
• Стабільні 60 FPS рендеру мапи при до 10 000 видимих треків.
• Pan-and-zoom відгукуються на типових тактичних масштабах мапи (від 1:50 000 до 1:1 000 000).
• Обмежена пам'ять — браузер має працювати весь день без витоків. Профілюйте кожний реліз.

Цілі досяжні з обраним стеком; промахи зазвичай — наслідок архітектурного зрізаного кута раніше в пайплайні (server-side фільтрація не реалізована, повні payload замість deltas, наївне керування станом).

Що далі

Частина 3 побудувала СОК. Треки рендеряться з коректною символікою; оновлення стримляться через WebSocket; оператори бачать лише те, на що вони авторизовані; ергономіка підтримує реальні операції. Платформа тепер придатна для оператора — але ще не для відвантаження.

Частина 4 закриває цикл: мости сумісності з НАТО (CoT, MIP4, STANAG 4559), маркування класифікації та примус releasability, DevSecOps-пайплайн, що видає докази для акредитації, і повітряно-ізольоване розгортання для тактичного edge. Після частини 4 платформа є операційно розгортуваною.