Командир роти, що чекає на боєприпаси на передовій патрульній базі, не знає, чи колона поповнення вийшла з району бригадної підтримки двадцять хвилин тому, чи ще завантажується. JLOGSTAT показує наявні запаси на рівні бригади. GCSS-Army має заявку в системі. Але фактичне місцезнаходження вантажівки з боєприпасами — і чи вони справді були завантажені — невідоме, доки хтось не вийде на зв'язок по радіо. Це розрив у видимості військової логістики, і він коштував людських життів та зірваних місій стільки, скільки існують армії.
Платформа візуалізації військової логістики закриває цей розрив, оснащуючи кожен вузол ланцюга постачання — склади, пункти накопичення, передові логістичні елементи, окремі транспортні засоби та контейнери — сенсорами, що безперервно передають місцезнаходження та стан ресурсів. Результатом є загальна логістична картина, яку командири та офіцери S4 можуть переглядати в реальному часі, не чекаючи наступного радіозвіту або пакетної синхронізації бази даних.
Ця стаття описує архітектуру такої платформи — від сенсорного рівня на передовій до рівня корпоративної інтеграції з існуючими військовими ERP.
Розрив у видимості логістики: чому дані JLOGSTAT і GCSS-Army застарілі
JLOGSTAT (Joint Logistics Status and Total Asset Visibility) і GCSS-Army (Global Combat Support System — Army) були розроблені для забезпечення видимості ланцюга постачання, і в межах своїх обмежень вони це роблять. Проблема в тому, що їхні моделі даних передбачають світ, де логістичні події вводяться людьми за стаціонарними комп'ютерами в пунктах підтримки ешелонів. Піддон, що прибуває в район бригадної підтримки, отримує запис про прийом лише тоді, коли клерк його скануватиме та підтвердить. Ця транзакція може відбутися у момент фізичного отримання або через кілька годин, коли клерк наздожене денну роботу.
Між районом бригадної підтримки і ротою формальної інфраструктури сканування часто взагалі немає. Заступник командира роти підписує квитанцію вручну. Сержант S4 вводить транзакцію наступного ранку. До того моменту, коли дані з'являються в GCSS-Army, боєприпаси вже витрачено, їжу з'їдено, а транспортні засоби заправлено — з точки зору логістичної інформації, подія відбулась через години після того, як сталась фізично.
Глибша проблема — архітектурна: обидві системи орієнтовані на пакетну обробку. Дані рухаються вгору по ланцюгу логістичної звітності за запланованими циклами, а не в реальному часі. Запис, що змінився на рівні роти, повинен пройти через вузли батальйону, бригади та дивізії, перш ніж стати видимим у спільному логістичному командуванні. На кожному вузлі запланований процес агрегує та завантажує дані. Практичний результат: зведені дані на вищих ешелонах зазвичай застаріли на 4–12 годин, а дані про окремі позиції нижче рівня бригадної підтримки можуть взагалі не існувати в системі.
Платформа візуалізації військової логістики не замінює ці системи — заміна застарілих військових ERP є десятилітньою програмою. Натомість вона працює паралельно з ними, забезпечуючи відстеження в режимі, близькому до реального часу, через окремий сенсорний і даний рівень, і передаючи транзакції назад до ERP, коли ресурс досягає формальної точки сканування.
Сенсорний рівень: пасивний/активний RFID, GPS-трекери, BLE-маяки
Три сенсорні технології охоплюють весь спектр вимог до відстеження військової логістики, і кожна має свою специфічну область застосування.
Пасивний RFID (EPC Gen2, ISO 18000-6C) є основою фіксованого відстеження логістики. Пасивна мітка — тонкий паперовий ярлик вартістю кілька центів — містить унікальний 96-бітний або 128-бітний ідентифікатор EPC. Коли піддон з такими мітками проходить через портальний зчитувач у воротах складу або в пункті накопичення, зчитувач активує мітки і збирає їхні ідентифікатори за мілісекунди. Зчитування порталу на відстані 3–5 метрів з майже 100% показником зчитування на правильно помічених піддонах є досяжним. Мітки не потребують обслуговування, батарей і витримують польові умови, включаючи пил, вологу та екстремальні температури. Обмеження — дальність: пасивний RFID не може відстежувати ресурси під час транспортування між фіксованими точками зчитування.
Активний RFID (433 МГц або 2,4 ГГц) вирішує задачу відстеження під час руху для сценаріїв середньої дальності. Активна мітка має власне джерело живлення і періодично транслює свій ідентифікатор. Встановлені на транспортних засобах зчитувачі в конвоях можуть опитувати активні мітки на всіх вантажах у радіусі 100–300 метрів, забезпечуючи поточний маніфест вантажу конвою без фізичного огляду. Активні мітки для оборонного застосування коштують 20–80 доларів США кожна, що робить їх економічно обґрунтованими для дорогого обладнання, але недоцільними для витратних матеріалів. Термін служби батареї — 2–5 років залежно від інтервалу передачі.
GPS/супутникові трекери забезпечують абсолютне позиціонування будь-де за наявності видимості неба. Захищений GPS-трекер, встановлений під капотом транспортного засобу або на вантажному контейнері, передає своє положення, швидкість і курс через стільникову мережу, супутник (Iridium/Inmarsat) або тактичне радіо до серверної частини платформи. Ключові критерії вибору: доступність зворотного каналу в районі операцій, наявність батареї або живлення від транспортного засобу, клас захисту навколишнього середовища (MIL-STD-810) та здатність трекера функціонувати під час руху в зонах перешкод GPS (можливість захисту GNSS від перешкод).
BLE-маяки (Bluetooth Low Energy) заповнюють прогалину там, де RFID і GPS не досягають: внутрішнє відстеження у складах, транспортних засобах і укриттях; моніторинг температури холодового ланцюга на окремих упаковках; відстеження предметів з високою щільністю на рівні взводу, де солдати носять індивідуальне спорядження. Мітки BLE коштують 3–15 доларів США, мають термін служби батареї 1–3 роки і можуть зчитуватися будь-яким смартфоном або планшетом із запущеним логістичним додатком у межах 30–50 метрів.
Агрегація даних: крайовий шлюз, ретрансляція MANET, кадансність завантаження через супутник
Передній край ланцюга постачання є зоною обмеженого зв'язку. Стільникове покриття може бути відсутнє або заглушено. Супутникові термінали використовуються спільно для різних функцій і мають обмежену пропускну здатність. Архітектура агрегації даних повинна справлятися з переривчастим і обмеженим зв'язком без втрати сенсорних подій.
Крайовий шлюз передового логістичного елемента (FLE) є першою точкою агрегації сенсорних даних. Це захищений обчислювальний пристрій — зазвичай промисловий ПК без вентилятора або вбудована система в транспортному кейсі — розміщений разом із FLE або бойовим поїздом. Він запускає RFID-зчитувачі, отримує дані від BLE-маяків сусідніх підрозділів і приймає звіти GPS-позиції від транспортних засобів у безпосередній зоні. Всі події зберігаються локально в буфері часових рядів. Шлюз підтримує постійну вихідну чергу: коли з'єднання доступне, він завантажує події в хронологічному порядку; коли з'єднання відсутнє, він продовжує записувати.
У тактичній зоні MANET (мобільна спеціальна мережа) забезпечує ретрансляцію подій між шлюзами і транспортними засобами без необхідності фіксованої інфраструктурної основи. Радіо MANET — TrellisWare TSM, Silvus StreamCaster або Persistent Systems Wave Relay — утворюють самовідновлювальну сітку, де будь-який вузол із шляхом до зворотного каналу може пересилати дані для вузлів, що не мають доступу. Агент ретрансляції платформи візуалізації працює на кожному вузлі MANET, пересилаючи сенсорні події до найближчої точки завантаження за моделлю зберігання та пересилання, яка витримує перебої зв'язку від хвилин до годин.
Кадансність завантаження через супутник повинна налаштовуватися для кожного оперативного контексту. У ході операції з високим темпом і достатньою пропускною здатністю завантаження сенсорних подій кожні 60 секунд забезпечує видимість у режимі, близькому до реального часу. В умовах обмеженої пропускної здатності, коли один VSAT-термінал ділиться між усіма підрозділами формування, реалістичнішими є пакетні завантаження кожні 15–30 хвилин. Платформа повинна коректно обробляти обидва режими, представляючи дашборди з чіткими індикаторами свіжості даних.
Архітектура платформи: прийом, часові ряди, геопросторові дані, дашборд
Серверна частина платформи дотримується багаторівневої архітектури з окремими компонентами для кожної функції.
API прийому приймає події від крайових шлюзів через MQTT (переважно для з'єднань з обмеженою пропускною здатністю — компактний двійковий формат, повторне підключення під управлінням брокера) та HTTP/REST (для шлюзів зі стабільним з'єднанням і наявними інструментальними ланцюжками HTTP). Теми MQTT структуровані ієрархічно: logistics/{theater}/{echelon}/{unit}/{asset_id}/position для GPS-треків, logistics/{theater}/{echelon}/{unit}/rfid/gate/{gate_id} для зчитувань порталів RFID. Рівень прийому перевіряє схеми подій, дедуплікує за UUID події та записує до сховища часових рядів.
База даних часових рядів зберігає треки позицій і показання сенсорів. InfluxDB і TimescaleDB обидва придатні; TimescaleDB є кращим для розгортань, що потребують складних JOIN між сенсорними подіями і реляційними даними реєстру ресурсів — це розширення PostgreSQL, що підтримує повний SQL. Політики збереження автоматично знижують дискретизацію старих даних: дані з повною роздільністю зберігаються 30 днів, потім знижуються до одного запису на 5 хвилин на 6 місяців, і до одного запису на годину надалі.
Геопросторовий рівень працює на PostGIS. Він зберігає геометрії логістичних об'єктів (межі складів, полігони пунктів накопичення, периметри передових операційних баз), мережі маршрутів і визначення геозон. Механізм геозон оцінює вхідні GPS-позиції відносно цих геометрій і ініціює події, коли ресурс входить у зону або виходить з неї — «колона увійшла в периметр бригадної підтримки» — що автоматично ініціює прийом товарів в ERP без необхідності сканування окремих міток клерком.
Веб-дашборд представляє загальну оперативну логістичну картину. Він поєднує шар карти MapLibre GL (що показує позиції ресурсів, маршрути конвоїв і накладення вузлів логістики) з табличними представленнями стану постачань, розрахунками запасів у днях і черговими запитами на поповнення. Рольовий контроль доступу забезпечує, що офіцери S4 роти бачать лише ресурси свого підрозділу, тоді як G4 бригади бачить повну картину формування.
Інтеграція TAK: логістичні треки на тактичній єдиній оперативній картині
Однією з найбільш оперативно значущих інтеграцій є передача логістичних треків ресурсів до ATAK (Android Team Awareness Kit) і CloudTAK, розміщуючи транспортні засоби постачання та контейнери на тій самій єдиній оперативній картині, яку тактичні командири використовують для відстеження своїх сил.
Інтеграція використовує протокол CoT (Cursor on Target). Платформа візуалізації запускає публікатор CoT, який запитує позиції ресурсів із бази даних часових рядів і публікує їх у вигляді XML-подій CoT на TAK-сервер. Кожен логістичний транспортний засіб стає сутністю CoT з унікальним UID, кодом типу, що вказує на його логістичну роль, і полями деталей, що містять стан навантаження, пункт призначення та розрахунковий час прибуття.
Логістичні треки слід публікувати на окремий шар TAK-карти, щоб тактичні оператори могли перемикати видимість логістики, не засмічуючи відображення транспортними засобами постачання під час контакту. Застарілі треки — ресурси, що не передавали оновлення позиції протягом встановленого порогового часу — повинні автоматично видалятися з єдиної оперативної картини, а не залишатися на їхньому останньому відомому місці.
Прогностична логістика: моделювання споживання та автоматичні тригери поповнення
Платформа візуалізації, яка лише показує, де знаходяться ресурси, корисна. Та, що прогнозує, коли вони закінчаться, і автоматично ініціює поповнення — трансформаційна.
Моделювання темпу споживання базується на історії транзакцій видачі. Щоразу, коли логістична подія реєструє отримання підрозділом пального, боєприпасів, пайків або інших матеріалів Класу постачання, платформа оновлює ковзний середній показник темпу споживання цього підрозділу. Найпростіша модель використовує ковзне вікно в 72 години: якщо 3-й взвод споживав 180 літрів пального за останні 72 години, його темп споживання становить 60 літрів на день. При 120 літрах, що залишились на руках, оцінка запасу в днях становить 2 дні.
Автоматичні тригери поповнення спрацьовують, коли оцінки запасів у днях опускаються нижче встановленого командиром порогу. Тригер, налаштований на «2 дні Класу III (пальне)», автоматично генерує заздалегідь заповлений запит на поповнення в ERP-системі та надсилає сповіщення черговому офіцеру S4. Запит містить підрозділ-ініціатор, необхідну кількість, місце доставки та класифікацію терміновості. S4 може затвердити та відправити запит однією дією або змінити його перед відправленням.
Оптимізація маршруту з урахуванням загроз інтегрує накладення загроз із тактичної єдиної оперативної картини — звіти про активність противника, заборонені зони, відомі маршрути з ризиком мін та саморобних вибухових пристроїв — у планування маршрутів конвою. Механізм маршрутизації платформи використовує модифікований алгоритм Дейкстри з зваженими загрозами вартостями ребер, щоб пропонувати маршрути, що балансують швидкість і ризик з дотриманням жорстких обмежень. Запропоновані маршрути представляються командиру конвою для затвердження — людський контроль над вибором маршруту зберігається.
Холодовий ланцюг та чутливі предмети: контроль температури та ланцюг зберігання
Певні категорії постачань потребують відстеження поза простим визначенням місцезнаходження: медичні витратні матеріали, вакцини, препарати крові та деякі боєприпаси мають вимоги до чутливості до температури, а чутливі предмети (криптографічне обладнання, певні зброєві системи, засекречені матеріали) потребують безперервних записів ланцюга зберігання.
Для моніторингу холодового ланцюга BLE-мітки температурних датчиків, прикріплені до охолоджуваних контейнерів або окремих групп упаковок, передають показання температури кожні 5–15 хвилин до найближчого шлюзу з підтримкою BLE. Платформа застосовує налаштовувані порогові значення сповіщень для кожної категорії предметів. Події перевищення порогу реєструються з точними часовими мітками та GPS-координатами, а відповідні предмети позначаються в логістичному дашборді для огляду перед видачею.
Для відстеження чутливих предметів платформа забезпечує двосторонню перевірку зберігання в кожній точці передачі. Подія передачі вимагає NFC або RFID-сканування як предмета, так і посвідчення особи отримувача, а також біометричного або PIN-підтвердження. Отриманий запис зберігання — UID предмета, особа, що передає, особа, що отримує, часова мітка, GPS-координати та підтвердження свідка — криптографічно підписується і зберігається в журналі аудиту лише з можливістю додавання.
Інтеграція з військовим ERP: GCSS-Army, ILMS-USMC, SAP Defense
Цінність платформи візуалізації зростає, коли вона передає дані про події в реальному часі назад до авторитетних ERP-систем, від яких залежить логістичне підприємство для постачання, фінансування та підзвітності.
Архітектура інтеграції використовує двонаправлений API-міст, що працює як мікросервіс між платформою візуалізації та ERP. Він підтримує таблицю відповідності між ідентифікаторами ресурсів платформи та номерами об'єктів ERP, обробляє автентифікацію до обох систем і виконує перетворення між моделлю подій платформи та моделлю транзакцій ERP.
GCSS-Army надає інтерфейс веб-сервісів (SOAP і все більше REST), через який можна програмно надсилати транзакції. Міст відображає події входу в геозону (ресурс прибув до BSA) на прийом товарів, події виходу з геозони (колона вийшла з FOB) на видачу товарів, а зчитування порталу RFID на переміщення між місцями зберігання.
ILMS-USMC (Integrated Logistics Management System for the Marine Corps) використовує аналогічний API на основі транзакцій. Конфігурація мосту відрізняється кодами транзакцій та відображенням полів, але шаблон інтеграції ідентичний.
SAP Defense (комерційна ERP, що використовується кількома союзниками по NATO) надає логістичні транзакції через функціональні модулі BAPI (Business Application Programming Interface) для синхронних операцій і через IDocs (Intermediate Documents) для асинхронних масових передач. Міст використовує BAPI для чутливих до часу транзакцій і IDocs для пакетного звірення наприкінці дня.
У всіх трьох випадках філософія інтеграції однакова: платформа візуалізації є системою взаємодії — вона фіксує реальні логістичні події в режимі, близькому до реального часу — тоді як ERP залишається системою обліку — вона зберігає авторитетні дані про запаси, фінанси та підзвітність. Міст тримає обидві системи синхронізованими, усуваючи ручне повторне введення, яке в даний час є основною причиною проблем із якістю даних у системах військово-логістичної інформації.
Ключовий висновок: Найвища цінність платформи візуалізації військової логістики полягає не у відстеженні — а в часі, зекономленому завдяки усуненню ручного введення даних у точках передачі. Бригада, що обробляє 200 логістичних транзакцій на день, кожна з яких потребує 3 хвилини роботи клерка, вивільняє 10 людино-годин щодня. За 180 днів розгортання це становить 1 800 людино-годин роботи клерка S4, перенаправлених на роботу вищої цінності.