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

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

Архітектура програмного забезпечення для управління військовим парком ЗСУ повинна враховувати ці обмеження з самого початку — не як запізнілі доповнення до комерційної платформи. Ця стаття охоплює відстеження транспортних засобів у складних умовах, управління технічним обслуговуванням та боєготовністю, моніторинг витрати палива, інтеграцію з ланцюгами постачання та архітектуру офлайн-першочерговості, яка забезпечує функціонування системи при відсутності зв'язку.

Відстеження транспортних засобів в умовах EMCON

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

Архітектурним рішенням є звітність із накопиченням та пересиланням зі змінними інтервалами звітування. Кожен транспортний засіб несе бортовий блок (OBU) — зазвичай захищений комп'ютер з GPS, інерційною навігацією та інтерфейсом тактичного радіо — який безперервно реєструє позицію, швидкість, курс та телеметрію транспортного засобу. Передача відбувається за розкладом або за командою: кожні 15 хвилин під час нормальних операцій, кожні 5 хвилин під час активного руху або повністю пригнічена в умовах суворого EMCON.

Формат даних позиції має значення. Системи відстеження військового парку кодують позицію за допомогою MGRS (Military Grid Reference System) або WGS-84 з відповідною точністю для оперативного масштабу. Звіти про позицію зазвичай відповідають формату треків NFFI або CoT XML для сумісності з системами C2, що відображають іконки транспортних засобів на загальній оперативній картині.

Архітектура бортового блоку

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

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

Відстеження технічного обслуговування та боєготовності

Боєготовність транспортного засобу — чи доступний він для операцій, перебуває в плановому технічному обслуговуванні, очікує на запчастини або виведений з ладу — є показником, про який найбільше піклуються командири ЗСУ. Командиру батальйону потрібно знати не лише скільки транспортних засобів у складі, але й скільки з них здатні виконувати завдання в будь-який момент.

Відстеження технічного обслуговування у програмному забезпеченні військового парку відповідає моделі даних, аналогічній TAMMS або її еквівалентам НАТО. Кожен транспортний засіб має запис технічного обслуговування, що включає: заплановані інтервали обслуговування (на основі лічильників кілометражу або мотогодин), історію несправностей, поточний оперативний статус (FMC — повністю боєздатний, PMC — частково боєздатний, або NMC — небоєздатний) та запчастини, що очікують на поставку.

Моніторинг витрати палива

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

Моніторинг палива OBU інтегрується з шиною CAN J1939 транспортного засобу, яка надає параметри двигуна, включаючи рівень витрати палива, загальне споживання палива з моменту останнього обслуговування та рівень паливного бака. Ці параметри реєструються з налаштовуваними інтервалами. Бекенд управління парком агрегує витрату палива на транспортний засіб для обчислення рівнів споживання на рівні формування, звірки з записами постачання та прогнозування вимог до поповнення запасів.

Інтеграція з системами ланцюга постачання

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

Інтеграція використовує стандартні військові формати логістичних даних там, де вони доступні — транзакції DLMS для запитів та надходжень запчастин, логістичні повідомлення NFFI для звітування про статус транспортного засобу до вищого ешелону. Там, де стандартні формати недоступні, інтеграція використовує REST API з JSON-пейлоадами.