Інтеграція JDLM та LOGFAS для планування коаліційного забезпечення

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

Відповіддю NATO на цю проблему є LOGFAS — пакет Logistics Functional Area Services — і невелике сузір'я допоміжних інструментів. Відповіддю США, з ширшим міжвидовим і міжвідомчим охопленням, є JDLM. На практиці кожне коаліційне розгортання має інтегрувати обидва, плюс власні ERP країн-учасниць. Ця стаття — інженерний огляд того, як така інтеграція реально працює, що ламається й що тримається.

Проблема коаліційного забезпечення

Національні армії за замовчуванням не федеруються. Кожна керує власною ERP — SAP в одних, Oracle EBS в інших, IFS у кількох, кастомні застарілі системи у більшої кількості, ніж визнається. Кожна має свій каталог матеріальних засобів, своє відображення NSN у локальні коди, свою схему транспорту, свої правила класифікації. Коли дві країни розгортають об'єднану оперативну групу, ніщо з цього не вирівнюється автоматично.

Історичним обхідним рішенням був LOGREP — LOGistics REPort — який обмінювали як плоский файл на конференціях планування. LOGREP став валютою коаліції: недосконалою, з втратами, але узгодженою. Список сил країни, готовність активів, прогноз споживання та план переміщень — усе згортається у записи LOGREP, які можуть читати інші коаліційні партнери. Сьогодні LOGREP досі є lingua franca, але обмін перемістився з паперу та електронної пошти в LOGFAS і протоколи навколо нього.

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

Огляд компонентів LOGFAS

LOGFAS — це не одна програма. Це пакет, який розповсюджує Агентство NATO зі зв'язку та інформації (NCIA), із чотирма компонентами, що мають значення для будь-якого інтеграційного проєкту.

LOGREP — це модель даних і база даних. Він визначає сутності — Force Modules, Holdings, Requirements, Stockpiles, Movement Requirements — і відношення між ними. Кожен інший компонент LOGFAS читає або пише LOGREP. Коли інженери кажуть «інтегруватися з LOGFAS», вони майже завжди мають на увазі «створювати або споживати вміст бази LOGREP».

ADAMS (Allied Deployment and Movement System) — це площина планування. ADAMS споживає LOGREP, застосовує мережу маршрутів, видів і транспортних активів і виробляє плани переміщень — хто переміщує що, яким способом, до якого проміжного вузла, якого дня. ADAMS — це там, де коаліційні планувальники проводять свої години на фазі розгортання.

EVE (Effective Visible Execution) — це шар моніторингу виконання. Там, де ADAMS планує, EVE відстежує фактичні дані: де насправді колона, чи літак справді вилетів, чи запас справді прибув. EVE — це найближче до картини реального часу, що є в LOGFAS, хоча «реальний час» у логістиці часто означає «сьогоднішні позиції, повідомлені о 07:00».

SDM (System Data Management) — це адміністративний хребет — користувачі, ролі, дозволи на розповсюдження, синхронізація баз даних, керування каталогами. SDM невидимий для планувальників і центральний для інтеграторів. Кожна крос-базова синхронізація, кожне узгодження каталогів, кожне правило releasability живуть тут.

Усі чотири взаємодіють через спільну базу LOGREP. Зміна Force Module в одному компоненті з'являється в інших під час наступної синхронізації. Більшість інтеграційних проєктів націлюються безпосередньо на схему LOGREP, розглядаючи ADAMS та EVE як представлення над спільним субстратом.

JDLM (Joint Deployment and Logistics Model)

JDLM — система моделювання Транспортного командування США (USTRANSCOM) для об'єднаного розгортання та забезпечення. Якщо LOGFAS зосереджений на коаліційному плануванні, то JDLM зосереджений на об'єднаних і міжвідомчих переміщеннях США — і дедалі більше на моделюванні, потрібному для оцінки альтернативних варіантів дій під обмеженнями.

JDLM споживає інший вхідний потік: TPFDD (Time-Phased Force and Deployment Data) із JOPES та його наступних систем, нативні для JDLM вхідні дані моделювання від планувальників і розвідувальні шари. Його виходи — це варіанти розгортання, оцінені за часом, пропускною здатністю режиму та ризиком. Історія взаємодії з LOGFAS — це не симетрія, дві системи не обмінюються базами даних. Це переклад. План США, змодельований у JDLM, має бути перевиражений як сумісні з LOGREP записи переміщень і holdings, щоб коаліційні партнери могли їх імпортувати.

На практиці це означає, що між ними сидить вузол перекладу — невелика служба, яка читає експорти JDLM, застосовує відображення полів, застосовує правила класифікації та записує вихідні дані у формі LOGREP у проміжний стейдж, з якого LOGFAS може забирати. Кожне коаліційне розгортання, що включає США, працює певною версією цього вузла.

Сімейство STANAG 2406

STANAG-и з логістичної звітності лежать в основі всього. STANAG 2406 охоплює логістичну звітність у широкому сенсі, а пов'язані STANAG-и з серії 2400 визначають конкретні формати обміну — звітність про пальне, боєприпаси, медичну логістику та втрати, звітність про транспортні переміщення.

Розширення MEDLOG — медична логістика — це частина, яку команди найчастіше недооцінюють. Медичний клас VIII має інші правила терміну придатності, інші температурні обмеження, інші профілі крос-національної releasability та іншу частоту звітування порівняно із загальним постачанням. Інтеграція LOGFAS, яка чисто обробляє класи I–V, усе одно провалить аудит на класі VIII, якщо MEDLOG не змодельовано коректно. Плануйте це з першого спринту.

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

Патерни інтеграції

Домінують три патерни.

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

Push (потік подій у LOGFAS). Висхідні системи відправляють події зміни — оновлення запасу, виконане переміщення — у шину повідомлень, а адаптер LOGFAS їх споживає й записує в LOGREP. Push ближчий до реального часу й без втрат, але вимагає надійної черги повідомлень і ретельної ідемпотентності. Для даних виконання правильним є push.

Staging (вузол перекладу з шлюзом класифікації). Канонічний коаліційний дизайн. Національні ERP публікують у національний стейдж. Вузол перекладу — належний інтеграційній команді, часто ізольований air-gap від upstream — читає зі стейджу, застосовує відображення полів, застосовує правила releasability й записує у коаліційний LOGREP. Вузол перекладу — це єдине вузьке місце, де сходяться класифікація, releasability та схема. Будуйте його явно. Не дозволяйте йому виникати самому.

Класифікація та releasability

Національні логістичні дані за замовчуванням є національними. NATO RESTRICTED — це підлога, на якій сидить більшість коаліційних обмінів, але той самий запис може бути releasable для NATO і не для конкретної партнерської країни, або releasable для однієї місії й не для іншої. Releasability — це не класифікація — це ортогональна вісь, що визначає, хто бачить що в межах заданого рівня класифікації.

Шаблон, який працює, — це санітизація на виході (sanitize-on-egress). Кожен запис несе вектор releasability — набір країн і місій, для яких він схвалений. Вузол перекладу відмовляється записувати будь-який запис, чий вектор releasability не включає призначення. Поля, що є національно чутливими (конкретні номери партій, імена постачальників, серійні номери кінцевих виробів), видаляються або хешуються, перш ніж запис перетне шлюз. Дисципліна коаліційної сумісності вимагає, щоб це примусово виконувалося в коді, а не в політиці. Політика провалюється під операційним темпом.

Шлюз також веде журнал. Кожен запис, що перетинає, кожен запис, що відхиляється, кожне поле, що санітизується — журналюється з походженням. Аудити releasability обов'язково прийдуть. Будьте готові.

Федерація національних ERP у LOGFAS

SAP, Oracle EBS, IFS та Maximo — чотири upstream-джерела, які ми найчастіше бачили. Кожне відображається в LOGREP по-різному.

SAP MM (Materials Management) несе holdings та споживання з високою точністю, але використовує національні матеріальні коди — відображення їх у NSN — це половина роботи з інтеграції. Відображення рідко є один-до-одного; очікуйте курований cross-walk, який підтримує орган управління матеріальними засобами. Патерни інтеграції оборонних ERP застосовуються тут безпосередньо.

Oracle EBS Inventory та IFS Supply мають подібну форму, але різну семантику полів — «on hand» в одній — це «available» в іншій, з резервуваннями та in-transit, що обробляються непослідовно. Читайте визначення полів, а не назви полів.

Maximo, що активно використовується для обслуговування парку техніки, постачає дані про готовність — стан транспортних засобів, відкладене обслуговування, частку mission-capable. Maximo живить стовпці готовності запису Force Module LOGREP. Неправильно змоделюйте готовність — і коаліційний план побудовано на вигадці.

Для конвеєра правильною формою є change-data-capture (CDC). Запустіть CDC проти ERP, матеріалізуйте національну проєкцію, трансформуйте у форму LOGREP, пропустіть через шлюз releasability й запишіть на іншу сторону. Пакетна реплікація ламається на крайніх випадках; покрокова дисципліна CDC їх ловить.

Операційні висновки

Навчання Steadfast Defender та Trident Juncture обидва стрес-тестували коаліційну логістику від початку до кінця у масштабах, близьких до реальної війни. Шаблон провалів послідовний.

Першим ламається каталог. Локальний каталог країни дрейфує від погодженого cross-walk NSN — нова номенклатура з'являється на службі, оновлення cross-walk відкладається, і за ніч стрічка LOGREP видає рядки «unknown materiel», які downstream-споживачі мовчки скидають. Вбудуйте виявлення дрейфу каталогу в конвеєр. Сповіщайте про це у ту ж зміну, коли воно сталося.

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

Третьою ламається releasability. Поле, яке було releasable вчора, сьогодні стає національно чутливим — ім'я постачальника, номер партії, деталь маршруту. Якщо releasability жорстко прописана у правилах перекладу, а не несеться per-record, кожна зміна стає релізом коду. Робіть releasability даними, а не кодом.

Четвертим ламається людина в циклі. Планувальники ADAMS та оператори EVE працюють позмінно, і передача між змінами — це там, де входить більшість регресій якості даних. Переміщення частково оновлюється вихідною зміною, нова зміна припускає, що запис фінальний, і downstream-споживачі поглинають недописаний план. Виправлення — не навчання. Виправлення — це примусове забезпечення record-level atomicity на межі LOGREP — часткові записи відхиляються, повні оновлення проходять. Перенесіть обмеження у шар схеми, де змінна втома не зможе його обійти.

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

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