Управління збором SIGINT: постановка завдань, деконфліктинг і пріоритизація

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

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

Що таке управління збором

Управління збором розташоване між процесом формування розвідувальних вимог та окремим сенсором. З одного боку, аналітики та командири генерують потік запитань: які частоти використовує радарна мережа протиповітряної оборони супротивника? Чи передає підозрюваний логістичний вузол? Які підрозділи активні в квадраті XY? З іншого — є скінченна кількість сенсорів із конкретними вікнами покриття, діапазонами частот і лімітами одночасних завдань.

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

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

Управління вимогами до збору

Вимоги надходять до системи управління збором у структурованій ієрархії. Пріоритетні розвідувальні вимоги (PIR) відображають найважливіші потреби командира в розвідувальних даних на стратегічному або оперативному рівні. PIR розкладаються на розвідувальні вимоги (IR) — конкретніші питання, прив'язані до певних цілей, географічних районів або часових вікон. IR своєю чергою розкладаються на конкретні вимоги до збору (SIR) — атомарні, придатні для виконання сенсорами завдання, що визначають, який сигнал шукати, у якому частотному діапазоні, в якому місці й у якому часовому вікні.

Фреймворк COLISEUM (Collection Operations Intelligence Schedules and Execution Unified Management), що використовується в розвідувальних системах NATO, формалізує цю ієрархію й додає поля для запитувача, пріоритету, обґрунтування та необхідного терміну збору. Записи вимог у стилі COLISEUM мають унікальний ідентифікатор, який зберігається протягом усього ланцюжка від збору до звітності, забезпечуючи наскрізну простежуваність — від питання командира до отриманого розвідувального продукту.

У програмному аспекті база даних вимог зберігає кожен SIR як запис із такими ключовими полями: ідентифікатор цілі, частотний діапазон або клас сигналу, географічна зона інтересу (полігон або точка з радіусом), часове вікно (часові мітки «не раніше» та «не пізніше»), рівень пріоритету (як правило, 1–5 або P1–P5), підрозділ-запитувач та критерії задоволення — що вважається успіхом збору. Планувальник читає цю базу даних як вхідні дані й намагається побудувати план завдань для сенсорів, що задовольняє якнайбільше вимог у межах можливостей наявного сенсорного парку.

Інвентаризація сенсорів та моделювання їхніх можливостей

Ефективне планування потребує точної моделі сенсорного парку в реальному часі. Система управління збором підтримує реєстр сенсорів, що фіксує такі атрибути кожного засобу збору:

Частотне покриття. Кожен сенсор має перелаштовуваний діапазон (наприклад, від 20 МГц до 3 ГГц) та миттєву смугу пропускання (наприклад, 40 МГц миттєвого покриття). Сенсор не може одночасно охоплювати частоти, що виходять за межі його миттєвої смуги, тому широкосмугові вимоги можуть потребувати або кількох сенсорів, або послідовних проходів перелаштування.

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

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

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

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

Алгоритми постановки завдань і планування

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

Найпростіший практичний підхід — жадібний планувальник із сортуванням за пріоритетом. Вимоги сортуються за рівнем пріоритету, потім за терміновістю часового вікна (вимоги з найближчим дедлайном — першими в межах кожного рівня). Планувальник ітерує по відсортованому списку та призначає кожну вимогу найкращому доступному сенсору — тому, що має найвищий запас відношення сигнал/шум для цієї цілі, або тому, що має найбільшу залишкову ємність одночасних завдань. Алгоритм працює за час O(R log R + R·S), де R — кількість вимог, S — кількість сенсорів, і дає достатньо гарні рішення для оновлень у реальному часі.

Для довших горизонтів планування формулювання задачі задоволення обмежень (CSP) або змішаного цілочисельного лінійного програмування (MILP) дають глобально кращі плани. Планувальник MILP мінімізує загальну незадоволену кількість вимог, зважену за пріоритетом, при дотриманні обмежень: за ємністю кожного сенсора, частотної реалізованості, географічного покриття та реалізованості часового вікна. Комерційні рішувачі (GLPK, HiGHS, CBC) вирішують задачі практичного розміру — сотні вимог, десятки сенсорів — менш ніж за хвилину. Жадібний планувальник обробляє оновлення в реальному часі; MILP виконується як періодичний пакетний процес для оптимізації горизонту планування.

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

Деконфліктинг

Деконфліктинг — це процес запобігання ситуації, коли два накази на завдання призводять до конфліктного або надлишкового збору. В управлінні збором SIGINT виникають два типи конфліктів.

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

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

Геометрія геолокації — ключовий фактор у цільовому деконфліктингу. Один сенсор дає лише пеленгаційну лінію, а не точку. Два сенсори дають точку лише за умови, що їхня геометрична база відносно цілі забезпечує прийнятне ослаблення точності (DOP). Тому рушій деконфліктингу дозволяє — і активно рекомендує — призначення кількох сенсорів до однієї цілі, коли точність геолокації є завданням збору, за умови що два сенсори розташовані для забезпечення достатнього кутового рознесення. Це скоординоване покриття, а не надлишкове, і ці два випадки потребують різної обробки в логіці деконфліктингу.

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

Перепостановка завдань у реальному часі

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

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

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

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

Інтерфейс командування і управління сенсором повинен підтримувати доставку завдань із низькою затримкою. Накази на перепостановку завдань, що надсилаються по каналах із великою затримкою — супутниковий SATCOM із 600 мс часу кругового маршруту — вимагають, щоб планувальник враховував затримку поширення команди при обчисленні найранішнього можливого часу перепостановки завдань сенсора. Завдання, видане в момент T, не повинне плануватися до початку раніше T плюс затримка поширення плюс час обробки на стороні сенсора.

Метрики та зворотний зв'язок

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

Основна метрика — рівень влучань збору: частка запланованих завдань, що були виконані та дали придатний розвідувальний продукт у межах часового вікна вимоги. Рівень влучань обчислюється за рівнем пріоритету, за сенсором, за типом цілі та за часовим періодом. Рівень влучань P1 нижче 90% — це проблема системного рівня, що потребує негайного розслідування. Рівень влучань P4 у 60% може бути прийнятним з огляду на обмежений сенсорний парк.

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

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

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

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

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

Докладніше про ширшу платформу, з якою інтегрується управління збором, дивіться у наших статтях про компоненти платформи SIGINT та архітектурне проектування платформи SIGINT.