Кожна серйозна платформа військової розвідки рано чи пізно стикається з однією й тією самою структурною проблемою: п'ять або більше розвідувальних дисциплін формують дані у власних форматах, з різною швидкістю та семантикою — а аналітикам потрібна єдина картина, яка одночасно охоплює їх усі. Повний посібник із злиття оборонних даних описує конвеєр обробки в широкому сенсі. Ця стаття заглиблюється у рівень схеми — канонічну модель даних, що лежить під рушієм злиття й дає йому когерентну основу для роботи.
Правильне проєктування моделі даних — це не другорядна деталь. Погано спроєктована схема переносить INT-специфічну логіку в прикладний рівень, робить крос-джерельні запити ненадійними і перетворює міграції схем на багатотижневе заморожування платформи. Добре спроєктована модель поглинає нові типи INT, підтримує бі-темпоральні запити та зберігає походження даних на кожному етапі злиття. У цій статті розглядаються всі рішення, що визначають, до якої категорії відноситиметься ваша платформа.
Чому кожна INT вимагає окремої адаптації схеми
П'ять основних розвідувальних дисциплін відрізняються не лише тим, що вони збирають, а й тим, як структуровані ці дані, з якою швидкістю вони надходять і яка метадані є невід'ємно доступними. Ці відмінності не є поверхневими. Вони визначають, яка логіка адаптера потрібна перед тим, як уніфікована модель зможе поглинути джерело, і обмежують, які крос-INT запити є можливими.
HUMINT (людська розвідка) є переважно текстовою. Звіт HUMINT — це наративний документ, що описує, що спостерігало, чуло або дізналося джерело. Часові мітки часто неточні — звіт може описувати подію, що відбувалася протягом кількох днів, з невизначеністю як у часі, так і в місці. Найважливіша метадані — оцінка джерела: наскільки надійне це конкретне джерело і наскільки достовірна ця конкретна інформація? Швидкість потоку даних HUMINT є низькою — від десятків до сотень звітів на день у завантаженому пункті збору, а не тисячі на секунду.
SIGINT (сигнальна розвідка) — що охоплює як COMINT (комунікаційна розвідка), так і ELINT (електронна розвідка) — є високошвидкісною, чітко структурованою та прив'язаною до часу з точністю до мілісекунди. Перехоплення або виявлення джерела SIGINT містить частотні параметри, кути пеленгування, фіксацію різниці часу приходу сигналу та характеристики модуляції. Семантичний зміст (що було сказано) часто класифікується окремо від параметрів сигналу. Швидкість потоку даних SIGINT може досягати мільйонів записів на годину у сучасній системі збору, що охоплює оспорюване електромагнітне середовище.
IMINT (розвідка на основі зображень) формує структуровані записи спостережень, отримані в результаті аналізу зображень: обмежувальні прямокутники з мітками класу сутностей та оцінками достовірності, координати геолокації, розмір пікселя на місцевості та часова мітка збору. Один прохід супутника або дрону може генерувати тисячі записів виявлення об'єктів. Труднощі полягають у тому, що виявлення IMINT — це просторові моментальні знімки: вони показують, де щось було у конкретний момент, а не куди воно рухається.
OSINT (розвідка з відкритих джерел) є структурно найнеоднорідніший. Вона включає публікації в соціальних мережах, новинні статті, аналіз комерційних супутникових знімків, дані відстеження польотів і морські AIS-потоки. Кожен тип джерела має власну схему. OSINT також є найменш контрольованим — якість джерел варіюється від авторитетних урядових публікацій до анонімних неперевірених заяв у соціальних мережах.
MASINT (вимірювальна та сигнатурна розвідка) охоплює вимірювання фізичних явищ: сейсмічних, акустичних, ядерного випромінювання, хімічних/біологічних сигнатур і профілів ефективної поверхні розсіювання радарів. Спостереження MASINT часто є непрямими — вони виявляють явище (вибух, рух техніки, радіовипромінювання), а не безпосередньо ідентифікують сутність. Ланцюжок від спостереження MASINT до ідентифікації сутності вимагає явних кроків умовиводу, які необхідно змоделювати в схемі.
Наслідком для уніфікованої моделі є те, що схема повинна акомодувати цю різноманітність, не нівелюючи її. Відповіддю є типізований базовий конверт із дисциплін-специфічними розширеними корисними навантаженнями — шаблон проєктування, детально описаний у серії побудови конвеєра злиття оборонних даних, частина 1.
Канонічні типи сутностей для уніфікованої моделі
Відправною точкою проєктування схеми є визначення таксономії типів сутностей — вичерпного переліку реальних об'єктів, які платформа повинна відстежувати та аналізувати. Для більшості платформ військової розвідки шість типів сутностей охоплюють переважну більшість розвідувальних об'єктів:
- Особа — окремі люди: комбатанти, командири, посередники, цивільні особи, що становлять інтерес
- Організація — групи, підрозділи, мережі, командні структури
- Місцезнаходження — фіксовані географічні об'єкти: споруди, інфраструктура, орієнтири, іменовані райони інтересу
- Техніка — транспортні засоби, зброєві системи, датчики, засоби зв'язку
- Подія — дискретні випадки: зіткнення, вибухи, зустрічі, передачі
- Документ — захоплені матеріали, публікації, розвідувальні звіти як об'єкти аналізу
Кожен тип сутності має базовий набір полів, незалежних від конкретної INT — поля, які необхідно заповнити незалежно від того, яка розвідувальна дисципліна надала інформацію:
EntityCore {
entity_id: UUID // globally unique, immutable
entity_type: Enum // Person | Organization | Location |
// Equipment | Event | Document
classification: ClassMarkings // see provenance section
valid_time: TimeInterval // [start, end) when fact was true
transaction_time:TimeInterval // [start, end) when row was current
confidence: Float[0..1] // fused confidence across sources
source_obs_ids: UUID[] // contributing observation record IDs
schema_version: SemVer // for evolution compatibility
created_at: Timestamp
updated_at: Timestamp
}
Поза базовим конвертом кожен тип сутності має типізовані розширення атрибутів. Сутність «Особа» містить біометричні ідентифікатори, псевдоніми, громадянство та посилання на пов'язану організацію. Сутність «Техніка» містить тип платформи, серійні ідентифікатори (якщо відомі) та посилання на пов'язаний підрозділ. Сутність «Подія» містить клас події, посилання на залучені сутності та просторовий відбиток. Ці розширення зберігаються як типізовані корисні навантаження, прикріплені до базового конверта, а не як стовпці в базовій таблиці. Саме це розділення дозволяє схемі поглинати нові атрибути для одного типу сутності, не впливаючи на інші.
Той самий принцип розділення застосовується до внесків INT. Коли перехоплення SIGINT пов'язується із сутністю «Особа» (тому що IMSI було пов'язано з відомою особою), це посилання зберігається як запис спостереження з типізованим корисним навантаженням SIGINT, що вказує на UUID сутності «Особа». Сама сутність «Особа» не містить SIGINT-специфічних стовпців — такий зв'язок зробив би схему вразливою до будь-яких змін у зборі SIGINT.
Походження даних та відстеження джерел
Походження даних є найважливішою нефункціональною вимогою будь-якої моделі даних розвідки. Кожен фрагмент інформації у злитій картині повинен бути простежуваним до початкового спостереження, системи збору, що його сформувала, і оцінок людини щодо його надійності. Без цього ланцюжка аналітики не можуть оцінити якість картини, з якою вони працюють, а платформа не може виконати відкат, коли джерело виявляється ненадійним.
Блок походження, прикріплений до кожного запису спостереження, повинен містити щонайменше:
ProvenanceBlock {
int_type: Enum // HUMINT | SIGINT | IMINT | OSINT | MASINT
source_id: UUID // internal source registry reference
source_reliability: Char // A–F (NATO admiralty scale)
info_credibility: Integer // 1–6 (NATO admiralty scale)
collection_time: Timestamp
report_time: Timestamp // when report entered system
originator: String // unit or system that produced report
classification: ClassMarkings
handling_caveats: String[] // NOFORN, ORCON, REL TO, etc.
dissemination_ctrl: String[]
}
Адміралтейська шкала кодує дві незалежні оцінки людини щодо кожного фрагмента розвідувальної інформації. Надійність джерела (від A до F) оцінює послужний список та достовірність джерела — джерело з рейтингом A було стабільно точним і надійним; джерело з рейтингом F має невідомий або поганий послужний список. Достовірність інформації (від 1 до 6) оцінює правдоподібність конкретної інформації незалежно від історії джерела — елемент із рейтингом 1 підтверджений іншими незалежними джерелами; елемент із рейтингом 6 є малоймовірним з урахуванням решти відомого.
Ці два рейтинги є оцінками людини, зробленими навченими офіцерами розвідки. Вони відрізняються від машинно розрахованої оцінки достовірності злиття на сутності і не повинні з нею змішуватися. Достовірність злиття відображає статистичну узгодженість між підтверджуючими джерелами; рейтинги адміралтейської шкали відображають людське судження про якість джерела. Обидва повинні зберігатися і надаватися аналітикам окремо.
Маркування класифікації вимагає структурованого представлення, а не вільного тексту. Тип ClassMarkings повинен кодувати: рівень класифікації (від UNCLASSIFIED до TOP SECRET), відділення та кодові слова, а також застереження щодо обробки у вигляді переліченого списку. Ця структура уможливлює програмне виконання контролю доступу — платформа може під час виконання запиту оцінити, чи відповідає допуск користувача класифікації кожного поля, і вибірково редагувати або утримувати поля, що перевищують рівень допуску користувача, а не відмовляти в поверненні всієї сутності.
Крос-INT розпізнавання сутностей
Розпізнавання сутностей — визначення того, що записи з різних джерел відносяться до однієї й тієї самої реальної сутності — є основною проблемою злиття, і вона є найбільш складною саме на крос-INT межі. В рамках однієї INT схеми ідентифікаторів є узгодженими: два записи SIGINT, що мають спільний IMSI, відносяться до одного пристрою. Між різними INT спільний ідентифікатор за замовчуванням відсутній. Виявлення IMINT транспортного засобу, фіксація пеленга SIGINT на випромінювач, розташований поряд із цим транспортним засобом, і звіт HUMINT, в якому названо особу, помічену в цьому транспортному засобі, повинні бути пов'язані через імовірнісний умовивід, а не через спільний ключ.
Конвеєр розпізнавання сутностей для уніфікованої моделі повинен обробляти три сценарії зв'язування:
Жорсткі зв'язки — спільні ідентифікатори, що однозначно пов'язують записи з однією сутністю. Відомий IMSI, номерний знак, зчитаний двома проходами IMINT, біометричний збіг. Жорсткі зв'язки повинні поширюватися автоматично без зниження достовірності.
М'які зв'язки — імовірнісні асоціації, засновані на схожості атрибутів у межах меж невизначеності. Два спостереження, що фіксують транспортний засіб того самого класу в координатах, що перекриваються, в часовому вікні, що відповідає можливому переміщенню між ними. М'які зв'язки несуть оцінку відповідності, розраховану рушієм розпізнавання.
Виведені зв'язки — асоціації, отримані з предметних знань: якщо пеленг випромінювача SIGINT стабільно рухається разом із треком транспортного засобу IMINT, вони, ймовірно, є однією платформою. Ці зв'язки вимагають явного визначення правил і мають нижчу достовірність, ніж м'які зв'язки, засновані на прямому перекритті атрибутів.
Конвеєр розпізнавання формує гіпотези відповідності. Гіпотези вище порогу високої достовірності автоматично зливаються в еталонний запис. Гіпотези в середньому діапазоні позначаються для перевірки аналітиком. Гіпотези нижче низького порогу зберігаються як окремі сутності. Порогові значення є настроюваними і повинні регулюватися для кожного типу сутності — злиття сутностей «Особа» вимагає вищих порогів достовірності, ніж злиття сутностей «Техніка», оскільки хибне злиття осіб має гірші аналітичні наслідки, ніж хибне злиття техніки.
Управління еталонними записами вимагає визначеної політики злиття для конфліктів атрибутів. Коли два джерела не збігаються в атрибуті — один звіт HUMINT говорить, що особа була в місці A, виявлення IMINT розміщує її в місці B годину потому — політика злиття повинна визначати, як узгодити атрибут в еталонному записі. Поширені політики включають: перемагає найновіший дійсний час, перемагає джерело з найвищою надійністю, зважена комбінація для числових атрибутів. Обрана політика повинна зберігатися в еталонному записі як метадані, щоб аналітики могли зрозуміти, чому еталонний запис відображає конкретне значення атрибута.
Модель злиття даних JDL формулює розпізнавання сутностей як проблему рівня 1 (уточнення об'єктів) і рівня 2 (уточнення ситуацій). Проєктування схеми, описане тут, є тим, що робить ці рівні JDL практично реалізованими.
Темпоральне моделювання: дійсний час і час транзакції
Бі-темпоральне моделювання не є факультативним для платформи військової розвідки. Це мінімальна темпоральна структура, необхідна для підтримки двох найважливіших типів запитів: «що було правдою у світі в момент часу T?» (запит за дійсним часом) і «що система знала про X станом на час T?» (запит за часом транзакції). Це різні питання, що вимагають різних відповідей, і схема, яка їх змішує — використовуючи одну часову мітку на запис — не може правильно відповісти ні на одне з них.
Дійсний час представляє, коли факт був правдою у реальному світі. Для виявлення IMINT транспортного засобу в координатах дійсний час — це часова мітка зйомки. Для звіту HUMINT, що описує зустріч, дійсний час — це найкраща оцінка аналітика того, коли відбулася зустріч — що може бути діапазоном днів, а не точною часовою міткою. Дійсний час є властивістю світу, а не бази даних.
Час транзакції представляє, коли запис був актуальним у базі даних. Для того самого виявлення IMINT час транзакції починається з моменту вставки запису виявлення і закінчується, якщо запис коли-небудь буде замінений (наприклад, якщо геолокація буде перероблена та виправлена). Час транзакції є властивістю бази даних, автоматично керованою системою.
Поєднання уможливлює дві критичні операції. По-перше, запити станом на час: «відновити повну розвідувальну картину, яку система мала о 14:00 дня D». Це вимагає запиту за часом транзакції — повернення лише записів, які були актуальними в базі даних о 14:00 дня D, незалежно від того, коли припадає їх дійсний час. Це є необхідним для аналізу після інциденту та аудиту рішень, прийнятих на основі розвідданих. По-друге, запити за историчними фактами: «які події відбулися в місці X між D-7 і D?» Це запитує за дійсним часом — повертаючи записи, інтервал дійсного часу яких перетинається з вікном запиту, незалежно від того, коли вони були вставлені.
Реалізація в PostgreSQL використовує стовпці періодів. Вимір дійсного часу представлено як стовпець tstzrange (діапазон часових міток з урахуванням часового поясу). Вимір часу транзакції використовує або системно-часову темпоральну таблицю (підтримується нативно в деяких розширеннях PostgreSQL), або явну пару стовпців transaction_start і transaction_end, де transaction_end встановлюється на нескінченність для поточних рядків і заповнюється при оновленні, щоб вказати, коли рядок був замінений. Усі оновлення повинні бути реалізовані як операції вставки-нового-рядка / маркування-старого-рядка, а не як перезапис на місці.
Контроль версій і лінійність для злитих об'єктів
Сутності розвідки не є статичними. Сутність «Особа» може починатися як попередня ідентифікація з єдиного звіту HUMINT, отримувати просторове підтвердження від виявлення IMINT через три дні і отримувати біометричне підтвердження від окремої події збору тиждень після цього. Кожне з цих оновлень змінює еталонний запис — але попередні стани повинні бути відновлюваними, а не перезаписаними.
Стандартна реалізація — журнал подій лише для додавання на сутність. Кожна зміна стану еталонного запису генерує подію оновлення. Кожна подія є незмінною після запису і містить:
- UUID сутності
- Тип події (Створено / Оновлено / Об'єднано / Розділено / Відкликано)
- Знімок попереднього стану (повна копія еталонного запису до зміни)
- Знімок нового стану
- Ідентифікатори записів спостережень, що спричинили оновлення
- Назва та версія застосованої політики злиття
- Часова мітка транзакції
- Ідентифікатор оператора (аналітик-людина або системний процес)
Поточний еталонний запис є результатом застосування всіх подій у послідовності від початку журналу. Це шаблон виникнення подій, застосований до розвідувальних даних. Він забезпечує повний аудиторський слід для кожного стану сутності в будь-який момент часу, що вимагається для відповідальності розвідки в більшості військових систем.
Відкат є операцією першого класу: за UUID сутності та цільовою часовою міткою транзакції платформа відтворює еталонний запис, яким він був у той момент, відтворюючи журнал подій аж до, але не включаючи події після цільового часу. Відкат ініціюється, коли джерело оцінюється як оманливе або помилкове — всі еталонні записи, що включали спостереження з цього джерела, повинні бути переоцінені з виключенням забруднених спостережень.
Подія відкликання є механізмом для обробки цього сценарію у масштабі. Коли джерело S анульовано, система генерує подію відкликання для кожного спостереження, приписаного S, а потім повторно запускає злиття для кожної сутності, що посилалася на будь-яке з цих спостережень. Сутності, підтримувані виключно відкликаним джерелом, повертаються до стану нижчої достовірності або позначаються як непідтверджені. Сутності, що мали підтверджуючі джерела від інших INT, поглинають відкликання зі штрафом до достовірності, але залишаються в картині.
Модель лінійності також уможливлює події розділення — протилежні розпізнаванню сутностей. Якщо дві сутності були помилково об'єднані (хибно-позитивне злиття), подія розділення роз'єднує їх: помилковий еталонний запис відкликається, і створюються два нові записи сутностей, кожен з яких успадковує записи спостережень, що правомірно належать їм. Подія розділення зберігає повну историю об'єднаного стану і рішення про розділення, дозволяючи пізнішим аналітикам зрозуміти, чому відбулося розділення.
Еволюція схеми у продакшн-середовищі
Платформа військової розвідки не є статичним продуктом. Нові системи збору виходять на лінію, нові дисципліни INT додаються до обсягу, а існуючі схеми потребують додавання атрибутів у міру появи нових аналітичних вимог. Еволюція схеми у продакшн-платформі, яка не може терпіти простоїв, вимагає навмисних рішень у проєктуванні з першого дня.
Основний принцип — зворотна сумісність як контракт. Базовий конверт сутності — поля EntityCore — повинен мати суворо версіоноване поле schema_version. Будь-яка зміна базового конверта, що видаляє поле або змінює тип поля, є критичною зміною і вимагає збільшення мажорної версії із визначеним шляхом міграції. Додавання необов'язкових полів до базового конверта є мінорною зміною версії. Поле версії дозволяє споживачам оголошувати, які версії схеми вони підтримують, і дає змогу платформі обслуговувати різні версії різним споживачам протягом перехідного période.
Розширені корисні навантаження є правильним засобом для додавання нових типів INT або нових атрибутів. Коли нова система аналізу зображень виходить на лінію і виробляє додаткові типи атрибутів (наприклад, оцінки пошкодження конструкцій, отримані із зображень SAR), ці атрибути потрапляють у нову або оновлену версію корисного навантаження розширення IMINT — а не в схему базової сутності. Існуючі споживачі, яким не потрібні специфічні для SAR атрибути, не зачіпаються.
Таксономія походження повинна розширюватися при додаванні нового типу INT. Перерахування типів INT отримує нове значення, а визначення рейтингів надійності і достовірності джерел повинні бути переглянуті на предмет застосовності до нового типу джерела. Деякі нові типи джерел можуть вимагати нових критеріїв достовірності, які не відображаються чисто на існуючу шестибальну адміралтейську шкалу — у таких випадках блок походження повинен містити вихідні метадані надійності, специфічні для джерела, на додаток до перекладеного рейтингу адміралтейської шкали, зберігаючи точність.
Правила розпізнавання сутностей є найбільш трудомістким шляхом еволюції. Коли новий тип INT приєднується до уніфікованої моделі, інженери з розпізнавання повинні визначити, як спостереження з нового джерела можуть бути пов'язані з існуючими типами сутностей. Це вимагає як аналізу даних (які атрибути доступні для зіставлення?), так і предметних знань (які порогові значення близькості атрибутів є оперативно значущими?). Ці правила повинні бути перевірені досвідченими аналітиками розвідки, а не лише програмними інженерами — некоректні правила розпізнавання призводять до хибних злиттів, що тихо руйнують розвідувальну картину.
Міграція схеми в бі-темпоральній моделі має додаткове міркування: историчні рядки повинні бути мігровані без зміни их истории часу транзакції. Міграція, що перезаписує існуючі рядки та оновлює их часові мітки транзакції, порушує семантику историчних запитів. Міграції повинні бути адитивними: додавати нові стовпці зі значеннями за замовчуванням для историчних рядків, а не оновлювати значення існуючих стовпців в историчних записах.
Тестування еволюції схеми вимагає багаторівневої стратегії: модульні тести для серіалізації та десеріалізації кожної версії схеми; інтеграційні тести для сумісності споживачів між версіями; і регресійні тести з використанням историчних зразків розвідувальних даних для підтвердження того, що існуючі запити повертають ідентичні результати після міграції. Тести з историчними даними найчастіше пропускаються і виявляють найбільше регресій, що руйнують продакшн-середовище.
Модель даних, описана в цій статті, є цільовим проєктом, а не відправною точкою для реалізації за один спринт. Більшість платформ будується до цієї архітектури поступово — починаючи з простішої схеми для двох-трьох типів INT і додаючи бі-темпоральну модель, повні блоки походження та лінійність на основі виникнення подій у міру закріплення оперативних вимог. Важливо те, що ключові рішення проєктування — типізовані розширені корисні навантаження, INT-агностичні конверти сутностей, розділені дійсний час і час транзакції — приймаються на ранньому етапі, оскільки їх адаптація до монолітної схеми є значно дорожчою, ніж їх вбудовування від самого початку.