Злиття розвідданих SIGINT, IMINT, HUMINT і OSINT в єдину узгоджену картину в теорії звучить просто. На практиці це одна з найскладніших інженерних задач в оборонній інфраструктурі даних. Кожна дисципліна створює дані з іншою швидкістю, в іншому форматі та з іншою моделлю достовірності, а система, яка лише агрегує ці потоки без справжньої кореляції, дає зашумленішу картину, ніж добре керований потік одного виду розвідки (INT), а не кращу. Серйозна інтеграція даних для оборонної розвідки потребує архітектури, спроєктованої з перших принципів навколо властивостей кожного типу джерела, а не універсального сховища даних із прикрученими адаптерами INT.

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

Проблема багатоджерельного злиття розвідданих — чому злиття SIGINT/IMINT/HUMINT/OSINT складніше, ніж здається

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

Різнорідність форматів — найпомітніша проблема. Запис перехоплення ELINT містить частоту випромінювача, інтервал повторення імпульсів, тип сканування, пеленг і дані про різницю часу надходження сигналу. Виявлення IMINT містить обмежувальну рамку, оцінку достовірності в піксельному просторі, розмір пікселя на місцевості та координату UTM із відповідним CEP. Наративний витяг HUMINT містить вільний текст, оцінку джерела від аналітика, іменоване місце та часове вікно, що вимірюється годинами або днями. Усі ці три записи можуть стосуватися того самого об'єкта реального світу — радіолокаційної машини, — але не мають спільного поля, спільної угоди щодо системи координат і спільного ідентифікатора. Нормалізація їх до єдиної канонічної схеми потребує спеціально створених адаптерів для кожного типу джерела та канонічної моделі сутностей, яка вміщує їх усі, не руйнуючи їхньої семантики. Проєктування моделі даних військового злиття даних датчиків multi-INT докладно охоплює цей канонічний шар.

Невідповідність достовірності менш помітна, але спричиняє більше аналітичних помилок. Кожен вид розвідки (INT) застосовує власну модель достовірності. Геолокація SIGINT має CEP (Circular Error Probable — кругове ймовірне відхилення) у метрах — оцінку геометричної точності. Виявлення IMINT має імовірність класифікатора — вихідний логіт нейронної мережі для класу об'єкта. HUMINT має адміралтейську оцінку надійності — шестибальну шкалу людського судження. Ці три числа означають принципово різне. Наївна система злиття, що усереднює їх, дає число, математично коректне, але аналітично безглузде. Правильна модель достовірності має спершу перевести притаманну кожному джерелу достовірність у спільну імовірнісну рамку, а потім агрегувати між джерелами за байєсівською схемою або схемою комбінування свідчень (як-от Демпстера — Шейфера), яка коректно обробляє залежні й незалежні свідчення.

Часовий перекіс — проблема, яка найпомітніше ламає архітектури злиття в реальному часі. Різні джерела мають вельми різні затримки від виникнення події до надходження даних у конвеєр. Перехоплення SIGINT може надійти в конвеєр протягом кількох секунд після передавання. IMINT із супутника, залученого до виконання завдання, може потребувати 60–90 хвилин обробки зображень, перш ніж буде створено запис виявлення. Звіт HUMINT, що описує вчорашні події, може бути прийнятий на день D+2. Рушій злиття, що корелює записи за часовою позначкою надходження в конвеєр, систематично хибно асоціюватиме події — він не зможе зв'язати перехоплення SIGINT і підтвердження IMINT, тому що вони надійшли з різницею 90 хвилин, хоча описують ту саму подію. Архітектура має розділяти час події (коли подія сталася у світі) та час приймання (коли повідомлення надійшло до конвеєра) і виконувати всю часову кореляцію за часом події, використовуючи час приймання лише для моніторингу продуктивності конвеєра.

Архітектура потокового приймання даних — Kafka і Pulsar для розвідувальних потоків, реєстр схем для різнорідних типів повідомлень, керування зворотним тиском

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

Основний архітектурний вибір на цьому шарі — між Apache Kafka та Apache Pulsar. Обидві системи розподілені, відмовостійкі та перевірені практикою в масштабі систем оборонного класу. Kafka має більшу екосистему та тіснішу інтеграцію з фреймворками потокової обробки — Kafka Streams і Apache Flink мають повноцінні конектори-джерела Kafka. Pulsar пропонує вбудовану мультиорендність, ізоляцію топіків на рівні просторів імен і розділену архітектуру обчислень і сховища. Для одноорендної платформи злиття, що працює в межах одного домену секретності, прагматичним вибором є Kafka. Для платформи, яка має ізолювати потоки за рівнем секретності, підтримувати розгорнуті на передовій вузли без зв'язку, що синхронізуються асинхронно з кластером тилового ешелону, або обслуговувати кілька організацій-орендарів, архітектура Pulsar надає чистіші примітиви ізоляції без ситуативних обхідних рішень.

Незалежно від вибору брокера, структура топіків має забезпечувати один топік на тип джерела, а не один топік на дисципліну INT:

# Угода про іменування топіків — один топік на тип джерела, а не на дисципліну INT, незалежно від вибору брокера; назва складається з рівня секретності, типу INT та ідентифікатора джерела: {classification}.{int-type}.{source-id}.raw ts.sigint.comint-system-alpha.raw ts.sigint.elint-collection-bravo.raw ts.imint.uav-sensor-charlie.raw ts.imint.sat-proc-delta.raw ts.humint.field-reports.raw ts.osint.ais-feed.raw ts.osint.social-monitor.raw # Нормалізовані вихідні топіки (після адаптера) — для них реєстр схем є обов'язковим ts.fusion.observations.normalized ts.fusion.entities.enriched ts.fusion.correlations.output

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

Керування зворотним тиском потребує обмежень швидкості для кожного типу джерела з класифікацією за пріоритетом. Джерела з високим пріоритетом — SIGINT і IMINT із діючих систем збору — ніколи не повинні обмежуватися за швидкістю. Джерела з низьким пріоритетом — масове приймання OSINT, завантаження історичних даних HUMINT — мають мати явні вагові коефіцієнти пріоритету, що дозволяють брокеру обмежувати швидкість їхніх споживачів, коли пропускна здатність конвеєра обмежена. У Kafka це реалізується через квоти груп споживачів і стратегії призначення партицій. У Pulsar обмеження швидкості на рівні просторів імен і квоти диспетчеризації забезпечують еквівалентний контроль. Архітектурні шаблони військового конвеєра розвідувальних даних докладно охоплюють керування чергами та проєктування груп споживачів.

Розпізнавання сутностей і дедуплікація — стратегії блокування для генерації кандидатів у сутності, оцінювання подібності на основі ML, злиття сутностей на основі графів

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

Наївний підхід — порівнювати кожне вхідне спостереження з кожною наявною сутністю — обчислювально нездійсненний у будь-якому реалістичному масштабі. Система збору ELINT, що створює 10 000 записів перехоплення за хвилину при корпусі з 50 000 активних треків сутностей, потребувала б 500 мільйонів порівнянь за хвилину ще до будь-якого оцінювання подібності. Стратегії блокування зводять це до керованого набору кандидатів, використовуючи структуру розвідувальних даних:

  • Геоклітинкове блокування — індексуйте кожну сутність за її оціночним місцезнаходженням за допомогою гексагональної сітки H3 з рівнем роздільної здатності 9 (клітинки площею приблизно 0.1 км²). Вхідне спостереження генерує пари-кандидати лише із сутностями в тій самій клітинці та в шести її безпосередніх сусідніх клітинках. Цей єдиний ключ блокування усуває понад 99.9% пар-кандидатів для просторових даних, водночас забезпечуючи високу повноту для справді спільно розташованих спостережень.
  • Часове блокування — обмежте кандидатів сутностями, чий інтервал чинного часу перетинається з конфігурованим вікном навколо часу події спостереження. Для рухомого транспортного засобу вікно має враховувати максимально можливу швидкість між останнім спостереженням і місцем поточного спостереження — танк не може подолати 50 км за 5 хвилин. Часове блокування без геоклітинкового блокування дає величезні набори кандидатів для будь-якої глобально активної сутності; обидва працюють разом як складений ключ.
  • Блокування за однозначним ідентифікатором — групуйте всі записи зі спільним детермінованим ідентифікатором (IMSI, результат OCR номерного знака, біометричний хеш, код транспондера Mode-S повітряного судна) в один кластер кандидатів незалежно від місця чи часу. Однозначні ідентифікатори оминають усі інші види блокування й розглядаються як остаточні сигнали злиття з урахуванням перевірки на дублікати самого ідентифікатора.
  • Блокування за спорідненістю типів INT — певні пари з різних видів розвідки структурно навряд чи збігаються й не повинні оцінюватися. Спостереження морського випромінювання SIGINT не слід оцінювати щодо треку наземного транспортного засобу IMINT. Правила спорідненості, що задаються для кожного типу сутності, відсіюють структурно неправдоподібні пари-кандидати до оцінювання.

Оцінювання подібності пар-кандидатів використовує модель градієнтного бустингу (XGBoost або LightGBM), навчену на розмічених парах «збіг / незбіг» з історичних розвідувальних даних. Вектори ознак включають: просторову відстань, нормалізовану на позиційну невизначеність; часову відстань, нормалізовану на обвідну швидкостей типу сутності; оцінку перекриття атрибутів для типізованих атрибутів (клас сутності, належність, тип техніки) і вагу сумісності типів INT. Модель виводить імовірність збігу в [0, 1]. Пари вище високого порогу (зазвичай 0.85–0.92) автоматично зливаються; пари із середньої зони спрямовуються на перегляд аналітиком; пари нижче низького порогу розглядаються як окремі сутності.

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

Архітектурна довідка
Конвеєр ототожнення сутностей — послідовність етапів
1
Блокування — формування пар-кандидатів за ключами геокомірок, часу та жорстких ідентифікаторів. Цільова повнота: >99,5% справжніх збігів у наборі кандидатів.
2
Виділення ознак — обчислення просторової відстані, часової різниці, збігу атрибутів і сумісності типів INT для кожної пари-кандидата.
3
ML-оцінювання — модель градієнтного бустингу видає ймовірність збігу для кожної пари. Пари із жорсткими ідентифікаторами оминають оцінювання й одразу потрапляють на об'єднання.
4
Маршрутизація за порогами — оцінка ≥ 0,88: автоматичне об'єднання. 0,55–0,87: черга перегляду аналітиком. < 0,55: відхилення (окремі сутності).
5
Об'єднання на графі — оновлення графа сутностей новими ребрами; повторне обчислення еталонних записів компонентів зв'язності; передавання оновлених сутностей у потік збагачених сутностей.
П'ятиетапний конвеєр ототожнення сутностей: від формування кандидатів до публікації еталонного запису.

Проєктування рушія кореляції — віконна кореляція (часова близькість), просторова кореляція (групування за геокомірками), семантична кореляція (зіставлення атрибутів сутностей)

Тоді як ототожнення сутностей запитує: «чи стосуються ці спостереження того самого об'єкта?», рушій кореляції запитує: «чи утворюють ці події за участі різних об'єктів змістовну закономірність?». Транспортний засіб, виявлений поблизу логістичного складу, а через 20 хвилин той самий транспортний засіб біля пункту заправлення, а потім — перехоплення SIGINT радіопереговорів, що узгоджуються з донесенням про позицію підрозділу з пункту заправлення: ці три події стосуються того самого транспортного засобу, але водночас описують ситуаційну закономірність (діяльність із поповнення запасів), яка аналітично значущіша за будь-яке окреме спостереження. Рушій кореляції створює цей розвідувальний об'єкт вищого порядку.

Кореляція працює одночасно в трьох площинах:

Часова кореляція групує події у вікна за часовими мітками подій і шукає закономірності спільної появи в межах кожного вікна. Визначення вікна налаштовується для кожного правила окремо: правило, що виявляє одночасний початок постановки завад і порушення зв'язку власних сил, може використовувати 30-секундне вікно; правило, що виявляє транспортний засіб на шляховій точці, за яким слідує інший транспортний засіб на тій самій шляховій точці, — 2-годинне вікно. Ковзні вікна (з перекриттям на половину тривалості вікна) гарантують, що події на межах вікон не буде пропущено. Віконна обробка за часом події із водяними знаками (watermarks) в Apache Flink — стандартний вибір для реалізації, бо вона коректно обробляє надходження подій у порушеному порядку, що критично для конвеєра, у якому IMINT і HUMINT мають дуже різну затримку приймання даних.

Просторова кореляція групує сутності за їхнім оціненим місцеположенням за допомогою групування за геокомірками з роздільністю, відкаліброваною під просторовий масштаб правила кореляції. Роздільність 8 у H3 (приблизно 0,7 км²) підходить для виявлення транспортних засобів, що діють в одній зоні; роздільність 6 у H3 (приблизно 36 км²) — для виявлення закономірностей діяльності в масштабі регіону. На відміну від блокування за геокомірками в ототожненні сутностей (якому потрібна висока повнота), просторове групування в кореляції потребує точності, що визначається правилом: правило кореляції, яке виявляє спільне розташування командної машини та логістичної машини, має використовувати дрібнішу комірку, ніж правило, яке виявляє постачальницьку діяльність у межах усього району. Правила самі задають власний параметр просторової роздільності, а не успадковують глобальне налаштування.

Семантична кореляція зіставляє сутності на основі значень атрибутів, а не просторової чи часової близькості. Сутність, класифікована як радіолокаційна станція протиповітряної оборони (РЛС ППО), що починає випромінювання, корелюється із сутністю, класифікованою як бойовий літак, що входить у зону покриття цієї станції: кореляцію зумовлює семантика атрибутів (тип радіолокатора порівняно з типом і траєкторією літака), а не те, що вони розташовані поруч. Семантичні правила кодують предикати атрибутів над типами сутностей: entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Ці вирази-предикати обчислюються потоковим процесором щодо кожної події оновлення сутності; коли всі предикати правила спрацьовують у межах вікна, спрацьовує й кореляція.

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

# Приклад визначення правила кореляції (YAML) rule_id: RESUPPLY-PATTERN-001 name: "Vehicle resupply sequence detection" description: "Detects a vehicle visiting a logistics node followed by a fuel point within window" confidence_weight: 0.72 spatial_resolution: H3_LEVEL_8 temporal_window_minutes: 90 events: - alias: VEH entity_type: EQUIPMENT attribute_predicates: - "attributes.platform_class IN [APC, IFV, TRUCK, LOGISTICS_VEHICLE]" - alias: NODE_VISIT entity_type: EVENT attribute_predicates: - "attributes.event_class == LOCATION_VISIT" - "attributes.location_type IN [LOGISTICS_NODE, DEPOT, FUEL_POINT]" linked_entity: VEH temporal_order: AFTER VEH.last_seen output: entity_type: SITUATION situation_class: RESUPPLY_ACTIVITY contributing_entity_refs: [VEH.entity_id, NODE_VISIT.entity_id]

Кожна спрацьована кореляція створює сутність Situation — новий розвідувальний об'єкт на рівні JDL Level 2, який посилається на UUID залучених сутностей, містить ідентифікатор правила та вагу впевненості правила й публікується в потік збагачених сутностей поряд зі стандартними оновленнями сутностей.

Оцінювання впевненості та походження даних — матриця надійності джерела × достовірності інформації (адміралтейська система НАТО), поширення впевненості на злиті сутності

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

Модель впевненості поєднує три вхідні складники. По-перше, вага надійності джерела, виведена з оцінки надійності джерела за адміралтейською системою НАТО: A=1,0; B=0,8; C=0,6; D=0,4; E=0,2; F=0,1. Ця вага масштабує внесок кожного спостереження від джерела в обчислення злиття. По-друге, вага достовірності інформації, виведена з адміралтейської оцінки достовірності: 1=1,0; 2=0,8; 3=0,6; 4=0,4; 5=0,2; 6=0,1. Ця вага застосовується до кожного спостереження незалежно від надійності джерела, оскільки надійне джерело може повідомляти непевну інформацію. По-третє, показник міжджерельної узгодженості — частка незалежних джерел, що підтверджують один одного й погоджуються щодо значення ключового атрибута, зважена за надійністю цих джерел. Значення позиції, підтверджене трьома джерелами з рейтингом A та оцінками інформації B2, отримує зовсім іншу оцінку, ніж підтверджене двома джерелами з рейтингом E та оцінками інформації D4.

Складена впевненість для атрибута обчислюється так:

# Формула впевненості для кожного злитого атрибута # Для кожного залученого спостереження i: # w_i = source_reliability_weight(admiralty_grade_A_to_F) # × info_credibility_weight(admiralty_grade_1_to_6) # # Зважена оцінка узгодженості: # agreement = sum(w_i for i in corroborating sources) # / sum(w_i for i in all contributing sources) # # Впевненість злиття: # confidence = agreement × source_coverage_penalty # # де source_coverage_penalty знижує оцінку для підтвердження лише одним типом INT: # 1.0, якщо підтверджують ≥ 2 різні типи INT # 0.75, якщо рівно 1 тип INT із ≥ 2 джерелами # 0.5, якщо рівно 1 джерело загалом

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

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

Публікація розвідувальної картини — публікація збагачених сутностей у системи C2 через CoT/NIEM, цільові показники затримки для розвідувальних даних, критичних за часом

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

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

Поле часу застарівання (stale time) CoT — природний механізм керування TTL на боці одержувача C2. Кожна опублікована подія CoT задає stale_time як entity_publication_time + entity_TTL. Приймальна система C2 (ATAK, CURSOR чи подібна) прибирає сутність зі свого відображення, коли stale_time спливає без оновлення. Система злиття має гарантувати, що сутності з активними спостереженнями отримують події оновлення CoT з інтервалом, коротшим за їхній TTL, — зазвичай на рівні 50% TTL, — щоб чинні сутності не зникали з картини під час нормальної роботи.

Цільові показники затримки визначають, як має бути реалізовано шар публікації. Для робочих процесів ураження цілей, критичних за часом, наскрізна затримка від події датчика до відображення в C2 має бути меншою за 30 секунд. Для цього потрібні: асинхронні неблокувальні воркери публікації; розпаралелена серіалізація CoT за партиціями сутностей; пріоритезовані вихідні черги, що віддають перевагу рухомим трекам із високою впевненістю перед оновленнями статичних сутностей; і пряма багатоадресна доставка TCP одержувачам C2 замість опитування REST API. Для загальної ситуаційної обізнаності на оперативному рівні зазвичай прийнятна затримка 60–120 секунд, що дає змогу застосовувати простіші синхронні шаблони пакетної публікації.

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

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

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

Керування TTL починається з призначення TTL під час створення сутності. Значення TTL залежать від типу сутності та рівня впевненості:

  • Трек рухомого транспортного засобу з високою впевненістю (впевненість ≥ 0,80, клас мобільності = WHEELED/TRACKED): TTL 8–15 хвилин
  • Рухомий трек із середньою впевненістю (впевненість 0,50–0,79): TTL 4–8 хвилин
  • Попередній трек із низькою впевненістю (впевненість < 0,50): TTL 2–4 хвилини
  • Стаціонарний об'єкт із високою впевненістю (впевненість ≥ 0,80, клас мобільності = STATIC): TTL 24–72 години
  • Сутність особового складу (на основі активності, а не позиції): TTL 30–120 хвилин залежно від типу останньої активності
  • Сутність Situation (похідна кореляція): TTL, що дорівнює найкоротшому TTL будь-якої залученої сутності, з обмеженням до 60 хвилин

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

# Згасання впевненості щодо позиції — експоненціальна модель # c(t) = c_0 × exp(-λ × t) # де: # c_0 = впевненість на момент останнього підтверджувального спостереження # t = час, що минув від останнього спостереження (секунди) # λ = константа згасання, залежна від типу сутності # # Константи згасання (ілюстративні): # TRACKED_VEHICLE: λ = 0.003 (період напіврозпаду ≈ 3.8 хв) # WHEELED_VEHICLE: λ = 0.004 (період напіврозпаду ≈ 2.9 хв) # SLOW_MOVER: λ = 0.001 (період напіврозпаду ≈ 11.5 хв) # STATIC_SITE: λ = 0.00001 (період напіврозпаду ≈ 19 год) # MARITIME_SURFACE: λ = 0.002 (період напіврозпаду ≈ 5.8 хв) # # Сутність переходить у стан STALE, коли c(t) < staleness_threshold # (зазвичай 0.15 для рухомих треків, 0.05 для статичних об'єктів)

Тригери повторної оцінки спрацьовують, коли надходить нове спостереження, узгоджене просторово й у часі із застарілою сутністю. Замість створення нової сутності для нового спостереження тригер спрямовує його через конвеєр ототожнення сутностей, розглядаючи застарілу сутність як кандидата. Якщо впевненість збігу перевищує поріг об'єднання, нове спостереження оновлює застарілу сутність: відлік TTL починається заново, впевненість перераховується за новим спостереженням (за потреби вгору від згаслого значення, якщо нове спостереження має високу впевненість), а сутність повертається зі стану STALE у стан ACTIVE. Оновлення фіксується як подія оновлення в журналі аудиту сутності.

Модель згасання слід також доводити до споживачів C2, а не лише застосовувати всередині системи. Публікація позиції з високою впевненістю в CoT без сигналу про те, що цій позиції 18 хвилин, змушує дисплей C2 показувати чітку, впевнену піктограму треку, яку аналітик може сприйняти як спостереження в реальному часі. Цю проблему вирішують два механізми: поле stale_time в CoT (розглянуте вище) гарантує, що сутність зникне з відображення, коли остаточно застаріє; а поле віку з моменту останнього спостереження, опубліковане в елементі detail CoT, дає аналітикові миттєве уявлення про те, наскільки давнє базове спостереження, навіть для сутностей, які ще не досягли свого часу застарівання. Деякі системи C2 використовують це поле для модуляції візуального подання впевненості — змінюючи непрозорість або розмір піктограми треку залежно від віку спостереження.

Разом сім архітектурних компонентів, описаних у цій статті, — приймання гетерогенних потоків, нормалізація з примусовим застосуванням схеми, ототожнення сутностей на основі блокування й ML, багатоплощинний рушій кореляції, багатошарове оцінювання впевненості, публікація CoT/NIEM і керування згасанням TTL — становлять повноцінну платформу злиття розвідувальних даних із багатьох джерел у реальному часі. Жоден із цих компонентів сам по собі не є новаторським. Архітектуру промислового рівня робить явне проєктування інтерфейсів між ними: канонічна схема спостережень, яку створює нормалізація й споживає ототожнення сутностей; формат графа сутностей, який створює ототожнення сутностей і споживає рушій кореляції; потік збагачених сутностей, який записують і ототожнення сутностей, і рушій кореляції, а читає шар публікації. Система, де ці інтерфейси неявні або не задокументовані — де кожен компонент припускає певну поведінку попереднього компонента в потоці, — крихка саме в тих точках, де розвідувальні дані найбільш мінливі за характером.