Управління теками цілей: побудова та супровід системи цілей

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

Тека цілі: модель даних та обов’язкові поля

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

Розташування та геометрія. Номіноване розташування цілі (NTL) — це координата WGS84, присвоєна під час номінації. У міру розвитку NTL уточнюється до середньої точки влучання (MPI) — координати, на яку наводитимуться засоби ураження. Тека цілі зберігає обидва значення з відповідними показниками точності: кругову ймовірну похибку (CEP) або еквівалентне твердження про точність даних з джерельної розвідки. Якщо ціль займає площу (склад, аеродром або командний вузол з кількома функціонально значущими компонентами), тека зберігає полігональний контур на додачу до MPI.

Ідентифікація та опис цілі. Кожна ціль отримує серійний номер цілі (TSN), присвоєний програмою цілевизначення при номінації. Додаткові поля ідентифікації включають категорію цілі (зі стандартизованого списку категорій цілей, узгодженого з доктринальними рамками аналізу системи цілей), назву цілі та перехресні посилання на наявні записи розвідувальної бази даних для того самого об’єкта. Розділ фізичного опису містить структуровані поля, що охоплюють розмір цілі, тип конструкції, наземну та підземну протяжність і відмінні риси, видимі на знімках.

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

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

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

Об’єднаний цикл цілевизначення та робочий процес програми

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

Фаза 1: Вказівки командира. Перед початком цілевизначення командир видає вказівки, що визначають систему цілей (яка категорія цілей підтримує цілі операції), бажані ефекти, обмеження та будь-які цілі, що є під забороною з огляду на оперативні, юридичні чи політичні міркування. Ці вказівки кодуються в програмі цілевизначення як конфігурація рівня кампанії: список затверджених категорій цілей, список обмежених і заборонених для ураження об’єктів (наповнений із баз даних списку обмежених цілей і списку заборонених для ураження) та порогові значення ефектів, які методологія CDE не повинна перевищувати без підвищеного командного затвердження.

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

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

Фаза 4: Застосування сил. Затверджені цілі додаються до об’єднаного переліку цілей і призначаються ударним платформам — авіації, артилерії чи засобам радіоелектронної боротьби — через бойове розпорядження авіації (ATO) або еквівалентний механізм постановки завдань. Програма цілевизначення фіксує призначення та оновлює статус цілі, відображаючи, що ураження заплановано. Інтеграція з шаром управління артилерійським вогнем C2 є ключовим інтерфейсом на цій фазі: програма цілевизначення має передати координати точок прицілювання, дані підривника та вимоги до ефекту системі управління вогнем і отримати підтвердження виконання у відповідь.

Фаза 5: Планування виконання та виконання. Після призначення офіцери цілевизначення відстежують статус виконання через інтеграцію програми цілевизначення з оперативною картиною C2. Коли платформа звітує про виконання — пуск зброї чи виконання вогню — програма цілевизначення фіксує подію виконання та запускає робочий процес BDA.

Фаза 6: Оцінювання. Дані оцінки бойової шкоди — знімки, сигнали чи наземні повідомлення — вносяться як структурований запис оцінки в теку цілі. Робочий процес оцінювання порівнює спостережувані ефекти з бажаними ефектами з Фази 1, класифікує результат (ціль знищено, ціль пошкоджено й потрібне повторне ураження, ціль не пошкоджено) та формує рекомендацію щодо повторного ураження, якщо бажаного ефекту не досягнуто. Завершений запис BDA закриває цикл цілевизначення для цієї цілі; цілі, що потребують повторного ураження, повертаються до JTL з оновленими теками.

Управління переліком цілей: JTL як жива база даних

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

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

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

Інтеграція списку заборонених для ураження та списку обмежених цілей

Список заборонених для ураження (NSL) і список обмежених цілей (RTL) мають бути інтегровані в програму цілевизначення на рівні даних, а не як перевірка на рівні інтерфейсу. Кожна тека цілі автоматично перехресно звіряється з NSL і RTL при введенні чи оновленні координат. Якщо MPI цілі потрапляє в межі порога близькості до захищеного об’єкта — лікарні, школи, об’єкта культурної спадщини чи релігійної споруди — програма позначає потенційний конфлікт і вимагає явного підтвердження від офіцера, що затверджує, перш ніж ціль можна просунути. Поріг близькості налаштовується для кожної категорії захищеного об’єкта та згідно з застосовними правилами ведення бойових дій.

Дані NSL і RTL ведуться як окрема контрольована база даних, що синхронізується до програми цілевизначення з вищого командування. Механізм оновлення має бути надійним і придатним для аудиту: кожна зміна NSL чи RTL фіксується з міткою часу, джерельним органом та конкретними доданими чи вилученими об’єктами. Цілі, чий статус близькості до NSL/RTL змінюється внаслідок оновлення NSL — а не переміщення цілі — мають бути повторно позначені для перегляду, навіть якщо їхні власні дані не змінилися.

Архітектура програми: база даних цілевизначення та її інтерфейси

Ядро програмного забезпечення для управління теками цілей — це структурована реляційна база даних зі сховищем документів для додатків — мініатюр знімків, знімкових продуктів повної роздільності, робочих аркушів CDE та звітів оцінювання. Реляційний шар містить запис цілі з усіма структурованими полями; сховище документів містить двійкові та великі текстові додатки, прив’язані до серійного номера цілі.

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

Інтеграційні інтерфейси з’єднують програму цілевизначення з рештою середовища C2. Основний інтерфейс — це шар COP, що споживає затверджені записи цілей із JTL як геопросторові накладення — опорні точки цілей, іменовані райони інтересу чи зони ураження, опубліковані як картографічні об’єкти. Цей інтерфейс двонапрямний: події виконання та вхідні дані BDA повертаються з шарів COP та ISR до бази даних цілевизначення. Вторинний інтерфейс з’єднує програму цілевизначення з системою координації вогню для прямого передавання даних точок прицілювання, параметрів зброї та підтвердження виконання. Див. суміжний розгляд програмного забезпечення координації JTAC та CAS щодо робочого процесу координації безпосередньої авіаційної підтримки, що діє паралельно з циклом виваженого цілевизначення.

Робота з секретністю та багатодоменний контроль доступу

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

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

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