Знати точно, хто присутній, хто поранений і хто зниклий безвісти, — одна з найстаріших вимог у військових операціях і одна з найважчих до виконання в хаосі бою. Паперові списки, усні переклички та передавані вручну доповідні про поранених служили арміям століттями, але вони вносять затримку, помилки переписування та прогалини обліку саме тоді, коли командири найбільше потребують надійних даних про особовий склад. Цифрові системи обліку особового складу замінюють цей аналоговий ланцюжок автоматизованими RFID-зчитувачами проходів, станціями біометричної реєстрації, структурованими робочими процесами звітування про поранених і панелями чисельності в реальному часі, які просувають точні дані про чисельність від відділення до театру в майже реальному часі. Ця стаття охоплює весь стек обліку: облік на вході за JRSOI, RFID-перекличку, біометричну реєстрацію та верифікацію ідентичності, керування категоріями поранених P1–P4, звітування про чисельність P-TRAP, інтеграцію з кадровими системами та системами грошового забезпечення, і захист біометричних даних для коаліційних середовищ.
Вимоги до обліку особового складу у військових операціях
Облік особового складу працює в кількох різних точках життєвого циклу розгортання, і кожна точка має різні обмеження збирання даних, вимоги терміновості та наступних споживачів. Розуміння цих різних контекстів запобігає розгортанню універсального рішення, яке розв'язує одну проблему обліку, ігноруючи інші.
Облік JRSOI. Joint Reception, Staging, Onward Movement, and Integration — перший вузол обліку для особового складу, що входить у театр. Кожен боєць, який прибув, має бути позитивно зіставлений із маніфестом розгортання, його ідентичність верифікована, а присутність зафіксована в системі обліку в театрі до того, як він залишить район приймання. JRSOI — також місце, де відбувається біометрична реєстрація осіб, раніше не зареєстрованих: фіксуються 10-відбитки пальців і зображення райдужки та зв'язуються зі службовим записом. Прогалина обліку JRSOI — боєць, чиє ім'я в маніфесті не збігається з пред'явленим посвідченням, або чий CAC не спрацював на зчитувачі, — має бути вирішена відділом S1 на місці, бо щойно боєць входить у сили без чинного запису обліку, він стає невидимим для кадрової системи.
Облік за розкладом нарядів. У межах підрозділу облік за розкладом нарядів відстежує, які бійці на службі в будь-який момент, а які — у відпустці, в тимчасовому відрядженні, на лікарняному або виконують інші обов'язки поза підрозділом. Розклад нарядів — основа щоденного звіту про чисельність. Цифрові системи розкладу нарядів пов'язуються безпосередньо з кадровою базою даних, автоматично отримуючи дозволи на відпустки та накази про тимчасові відрядження, щоб відділ S1 не звіряв паперові документи зі списком щоранку вручну. Будь-яка розбіжність між розкладом нарядів і фізичною перекличкою — боєць, позначений як присутній, якого не можна знайти, — спричиняє негайну перевірку обліку і, якщо її не вирішено в межах визначеного вікна, доповідну про зниклого безвісти.
Відстеження в пунктах збору поранених. У пунктах збору поранених (CCP) і медичних закладах (MTF) облік перетинається з медичним сортуванням. Кожен поранений, що прибуває до CCP, має бути ідентифікований (ідеально через сканування CAC або біометричне зіставлення), йому має бути призначена категорія сортування, і він має бути внесений у систему відстеження поранених. Запис обліку CCP живить і доповідну підрозділу про поранених, і маніфест медичної евакуації, гарантуючи, що боєць, відстежений як поранений відділом S1, — та сама особа, що з'являється в списку рейсу MEDEVAC. Дивіться нашу статтю про військові медичні застосунки TCCC щодо цифрових робочих процесів на рівні місця ураження та закладу лікування.
RFID-перекличка особового складу
RFID-перекличка автоматизує підрахунок, який інакше вимагав би від командира відділення викликати імена і фізично перевіряти присутність кожного бійця. Вбудовуючи пасивні UHF-мітки RFID у картки посвідчення, браслети або тримачі жетонів, система автоматично фіксує переміщення особового складу через ключові вузькі місця, оновлюючи сервер обліку без будь-якої дії самого бійця.
UHF RFID-портал-зчитувачі для переклички підрозділу
Портал-зчитувачі, встановлені на воротах входу та виходу з табору, складають основу гарнізонного обліку. Стандартний UHF RFID-портал використовує від двох до чотирьох антен, розташованих так, щоб створити зону зчитування на всю ширину воріт. Пасивні мітки в діапазоні 860–960 МГц (UHF RFID) відповідають на РЧ-поле зчитувача в межах 3–8 метрів, повертаючи унікальний Electronic Product Code (EPC), який зчитувач публікує на сервер обліку з міткою часу та локацією зчитувача. Для руху транспортних засобів мітки, встановлені на лобовому склі, фіксують облік транспортного засобу та екіпажу одночасно через ворота — одне проїжджання записує і рух засобу, і прохід особового складу.
Події зчитування проходів обробляє сервер обліку за набором правил, які визначають результуюче оновлення статусу:
- Зчитування входу на головних воротах — встановлює статус Присутній (На об'єкті), якщо раніше був Поза об'єктом.
- Зчитування виходу на головних воротах — встановлює статус Поза об'єктом, фіксує час відбуття; сповіщає S1, якщо боєць не має затвердженого пропуску чи наказу про відпустку.
- Зчитування входу в районі зосередження — позначає бійця як Зосередженого до руху, живлячи попередню перекличку перед місією.
- Зчитування входу в смузі посадки на літак — позначає бійця як Внесеного до маніфесту відповідного польотного серійного номера.
- Зчитування невідомої мітки — генерує сповіщення для служби безпеки; мітка не зареєстрована в базі даних обліку.
Інтеграція зі зчитувачами карток для CAC/PIV
Не кожна точка обліку може виправдати інфраструктурну вартість стаціонарного портал-зчитувача. Зчитувачі карток CAC/PIV — зчитувачі контактних смарт-карток або безконтактні NFC-зчитувачі, — дають дешевшу альтернативу для локацій з меншою пропускною здатністю: стійки реєстрації штабів підрозділів, роздавальні пункти автопарку, приймальні пункти зброї та пункти збору поранених. Зчитувач CAC витягує Card Holder Unique Identifier (CHUID) і опційно верифікує PIN або біометричне зіставлення на картці, потім публікує подію на сервер обліку. Оскільки CAC уже містить ідентифікаційну інформацію бійця та облікові дані PKI, окрема RFID-інфраструктура не потрібна — сама картка є токеном.
Ручний RFID для польового обліку
Стаціонарні зчитувачі не можуть покрити кожну вимогу обліку в розгорнутому середовищі. Ручні UHF RFID-зчитувачі — пристрої розміром приблизно з великий смартфон зі вбудованою спрямованою антеною, — дозволяють командирам відділень і взводів проводити позапланові переклички будь-де: районах зосередження, патрульних базах, передових опорних пунктах і зонах посадки гелікоптерів. Командир переміщує ручний зчитувач над зібраними бійцями, і пристрій фіксує кожне зчитування мітки в локальному списку переклички. Якщо пристрій підключено до тактичної мережі, зчитування синхронізуються з сервером обліку в реальному часі. У середовищі без зв'язку зчитування зберігаються локально і синхронізуються при відновленні зв'язності. Ручний пристрій показує, які зареєстровані бійці не були зчитані, спонукаючи командира фізично знайти або доповісти про кожного зниклого перед закриттям переклички.
Для інтеграції із системами відстеження дружніх військ на Android для військових портативні зчитувачі RFID можна поєднувати з пристроями Android, на яких працюють застосунки обліку особового складу; дані перевірки накладають на тактичну спільну картину бойової обстановки підрозділу, щоб командири бачили, яких солдатів у кожному квадраті сітки підтверджено, а які лишаються непідтвердженими.
Біометрична реєстрація та перевірка особи
Мітки RFID і картки CAC можна загубити, передати іншій особі або навмисно використовувати замість зареєстрованого власника. Біометрична реєстрація створює неможливий для підробки зв'язок між фізичними характеристиками людини та її обліковим записом і дає змогу однозначно перевіряти особу — такого не забезпечить жоден фізичний токен.
Реєстрація відбитків 10 пальців
Реєстрація за десятьма відбитками фіксує всі десять відбитків пальців — плоскими та валиковими знімками — за допомогою сертифікованого сканера відбитків. Військова реєстрація відповідає стандартам FBI/DOD щодо якості зображень (щонайменше роздільна здатність 500 dpi, оцінка якості NFIQ2 вище визначеного порога для кожного пальця). Знімки низької якості — через суху шкіру, порізи або бруд на сенсорі — слід відхиляти й одразу знімати повторно; реєстрація шаблону низької якості дає високу частоту хибних відмов під час перевірки. Для осіб, які не можуть зареєструвати всі десять пальців (ампутація, тяжкі опіки), альтернативні біометричні модальності — райдужка оболонки ока або обличчя — мають замінювати відсутні пальці.
Зареєстровані шаблони зберігають у центральній біометричній базі даних, пов'язаній з обліковим номером особи. Термінали перевірки на контрольно-пропускних пунктах зіставляють живий скан із збереженим шаблоном і повертають рішення «збіг/немає збігу» за 1–3 секунди. На пунктах із високою пропускною здатністю спершу зчитують картку CAC, щоб отримати конкретний шаблон для заявленої особи (верифікація 1:1) — це швидше й точніше, ніж пошук у всій базі даних (ідентифікація 1:N).
Реєстрація за райдужкою оболонки ока
Сканування райдужки оболонки ока — біометрія вибору для середовищ, де солдати носять рукавички й торкатися сенсора відбитків непрактично, або де потрібна швидка перевірка на відстані. Сучасні камери для одночасного знімання обох очей здобувають зображення обох очей на відстані 20–60 см і можуть працювати в ближньому інфрачервоному освітленні, що дає змогу реєструвати й перевіряти особу вночі. Шаблони райдужки компактні (менш як 1 КБ на око) і надзвичайно стабільні в часі — на відміну від відбитків пальців, візерунки райдужки не змінюються з віком чи фізичним зношуванням.
Для коаліційних операцій бази даних райдужки слід ретельно відокремлювати: поширення біометричних еталонних даних через національні кордони вимагає явних юридичних повноважень і угод про обмін даними. Система реєстрації має фіксувати правову підставу, на якій зареєстровано кожну особу, та умови, за якими її шаблон можна поширювати.
Інтеграція CAC/PIV і швидка перевірка на блокпості
Картка загального доступу (Common Access Card, CAC) і посвідчення верифікації особи (Personal Identity Verification, PIV) містять біометричний еталонний шаблон і сертифікат PKI безпосередньо на картці, що дає змогу офлайн перевіряти біометрію без запиту до центрального сервера. На блокпості зі зчитувачем карток, що підтримує біометрію, процес такий: вставити картку, прикласти пальця до засобу зіставлення на картці, отримати результат зіставлення від захищеного елемента картки. Уся транзакція триває 3–5 секунд і не потребує мережевого з'єднання. Ця можливість офлайн-перевірки критична для передових блокпостів, де зв'язок із біометричною базою даних не гарантовано.
Облік поранених і зниклих безвісти
Облік втрат — функція системи обліку особового складу, де ціна помилки найвища. Помилки у фіксації втрат — неправильне ім'я, неправильна категорія, затримка повідомлення — безпосередньо впливають на строки повідомлення найближчих родичів, точність позначок щодо грошового забезпечення та на картину втрат бойової могутності, яку бачить командир.
Керування категоріями втрат P1/P2/P3/P4
Чотири категорії пріоритету слід фіксувати в момент поранення та оновлювати на кожному наступному рівні надання допомоги. Цифрові системи обліку помітно відображають поточну категорію і ставлять часової мітки кожній зміні категорії, створюючи перевірюваний ланцюжок просування пораненого ланцюгом евакуації:
- P1 (Терміновий) — потрібне втручання для порятунку життя протягом 1 години. Система обліку негайно формує запит на MEDEVAC. Система одночасно сповіщає відділення S1 і медичного офіцера.
- P2 (Пріоритетний) — потрібне втручання протягом 4 годин. Формує пріоритетний запит на MEDEVAC і позначає пораненого для найближчого доступного засобу евакуації.
- P3 (Плановий) — втручання прийнятне протягом 8 годин. Пораненого планують до наступного планового вильоту для евакуації.
- P4 (Очікуваний/Зручність) — у масових втратах: поранення настільки тяжкі, що лікування спожило б непропорційно багато ресурсів; або в штатних операціях: легкі поранення, що потребують лише самообслуговування.
Під час масової втрати система має підтримувати одночасний ввід кількох поранених категорії P1 без перевантаження інтерфейсу. Рекомендований дизайн — режим швидкого вводу зі скануванням CAC або зчитуванням RFID, які автоматично заповнюють поля особи; медик лише підтверджує категорію і тип поранення — час вводу одного пораненого скорочується до менш ніж 30 секунд.
Цифровий робочий процес Casualty Feeder Report
Casualty Feeder Report (CFR) — документ підрозділу, який запускає офіційну процедуру обліку втрат. Цифровий CFR фіксує обов'язкові елементи даних і передає їх до відділення S1 у встановлений строк (зазвичай 1 година від події втрати для KIA/WIA, 4 години для DNBI). Цифровий робочий процес:
- Заповнення полів особи шляхом сканування CAC або ручного вводу зі звірянням зі списком підрозділу.
- Дані про подію втрати: група дата-час, місце (10-значна координата), обставини (контакт із противником, нещасний випадок, DNBI) та початкова категорія.
- Цифровий підпис офіцера, який подає звіт.
- Автоматична передача до відділення S1 батальйону тактичною лінією передачі даних із обов'язковим підтвердженням доставки для відповідності SOP.
- Автоматичне формування повідомлення звіту про втрати, відповідного до AR 600-8-1, для передачі до оперативного центру особового складу театру воєнних дій.
Інтеграція з JCAVS
JCAVS (Joint Casualty and Verification System) — система обліку рівня театру воєнних дій для верифікації втрат і повідомлень. Інтеграція системи обліку підрозділу з JCAVS потребує зіставлення елементів даних CFR зі схемою введення JCAVS і встановлення захищеного шляху передачі даних до оперативного центру особового складу театру. Добре інтегровані системи усувають повторний ручний ввід даних про втрати в JCAVS, що історично був джерелом помилок і затримок у повідомленні найближчих родичів. JCAVS повертає підрозділу номер відстеження втрати після отримання звіту; система обліку підрозділу фіксує його в записі особи як підтвердження прийняття.
Звітність про чисельність і P-TRAP
Звітність про чисельність перетворює індивідуальні записи обліку на зведену картину бойової могутності, якою командири користуються для планування та розподілу ресурсів. Основний результат — щоденний звіт про чисельність, але система обліку також формує на запит звіти про статус особового складу для планування операцій і післябойового аналізу.
Формування цифрового звіту про чисельність
Цифровий звіт про чисельність агрегує поточний статус обліку кожного солдата в стандартні категорії, потрібні для формату звіту: чисельність за списком, чисельність на службі, ефективна чисельність (присутні мінус непридатні до розгортання) та підсумки втрат за типами. Рушій формування звіту опитує базу даних обліку в налаштований час звітності (зазвичай за 30 хвилин до кінцевого строку подання) і створює звіт у потрібному форматі для електронної передачі старшому штабу. Командири можуть будь-коли переглядати живе передзвітне подання на панелі S1, що особливо цінно під час тривалих операцій, коли чисельність може змінюватися щогодини.
Робочий процес P-TRAP
P-TRAP (Personnel Tracking, Reporting, and Processing) — робочий процес і набір інструментів, які визначають, як відділення S1 збирають, перевіряють і подають дані про чисельність. У цифровому робочому процесі P-TRAP:
- Підлеглі підрозділи подають цифрові звіти обліку до відділення S1 батальйону у встановлений час звітності, замінюючи голосовий радіозвіт PERSTAT, для якого сержант мав опрацьовувати кожен підлеглий підрозділ послідовно.
- Інструмент S1 батальйону автоматично агрегує звіти підлеглих підрозділів і позначає будь-який підрозділ, який не подав звіт до кінцевого строку.
- Автоматизовані правила перевірки шукають типові помилки: підсумки чисельності, які не збігаються, статуси втрат без підтверджувальних CFR або показники ефективної чисельності, що свідчать про підрозділ нижче порога готовності до виконання завдання.
- Перевірений звіт про чисельність батальйону передають до відділення S1 бригади, яке виконує таке саме агрегування й перевірку перед передачею до дивізії.
- Увесь цикл звітності — від подання підлеглим підрозділом до отримання штабом театру — завершується менш ніж за 30 хвилин у повністю цифровій реалізації P-TRAP проти 2–4 годин для циклу на голосовому зв'язку та папері.
Інтеграція з панеллю S1
Панель S1 дає офіцеру з особового складу та штабу живий огляд чисельності підрозділу, організований за підлеглими підрозділами, ешелонами й категоріями статусу обліку. Критичні функції панелі для оперативного використання: сповіщення про пороги, коли ефективна чисельність будь-якого підрозділу падає нижче мінімуму командира (зазвичай 60–70% для бойових підрозділів); аналіз тенденцій втрат, що показує темп втрат чисельності за останні 24–48 годин; і трекер відновлення особового складу, який пов'язує прибуваючі поповнення з конвеєра JRSOI з підрозділами, куди їх призначають для доукомплектування.
Інтеграція з системами кадрового обліку та грошового забезпечення
Дані обліку особового складу мають прямі фінансові та юридичні наслідки далі за ланцюгом. Статус втрати, який не передали вчасно до системи кадрового обліку та грошового забезпечення, може призвести до місяців неправильних виплат пораненому або його родині — проблема, що завдає значних страждань і вирішується місяцями. І навпаки: позначка щодо грошового забезпечення, спричинена помилковим записом обліку, може безпідставно припинити виплати солдату. Автоматизована інтеграція між системою обліку та системою кадрів/грошового забезпечення має бути надійною, перевірюваною і спроєктованою так, щоб звести до мінімуму як хибні позначки, так і пропущені.
Зв'язок із TAPDB-G. Total Army Personnel Database – Global (TAPDB-G) — авторитетний запис особового складу Армії. Зміни статусу обліку, що впливають на офіційний запис — WIA, MIA, KIA і повернення до строю після кожної з них — породжують автоматизовані транзакції оновлення TAPDB-G. Ці транзакції використовують обліковий номер солдата як первинний ключ і містять підрозділ, що уповноважує, групу дата-час зміни статусу та цифровий підпис офіцера, який уповноважує.
Позначка щодо грошового забезпечення при статусі втрати. Коли підтверджено статус WIA або MIA, система обліку формує транзакцію позначки щодо грошового забезпечення до IPPS-A (Integrated Personnel and Pay System – Army) або відповідної національної системи. Позначка запускає перевірку прав на грошове забезпечення солдата: розпочинають виплату за вогневий контакт, якщо її ще не активовано, оцінюють спеціальну компенсацію, пов'язану з бойовими діями, і відображають дані бенефіціара Servicemembers' Group Life Insurance для офіцера з надання допомоги при втратах. Для солдатів зі статусом MIA позначка про розподіл утримує певні добровільні утримання до підтвердження статусу.
Тригери оновлення SRB/ORB. Оновлення Soldier Record Brief (SRB) і Officer Record Brief (ORB) спричиняють зміни статусу служби, що впливають на постійний запис: госпіталізація понад 30 днів, повернення до строю після госпіталізації, зміна з MIA на KIA або повернення під військовий контроль. Ці оновлення слід завершити в регламентований строк (зазвичай 5 робочих днів), щоб зберегти точність записів для кадрових комісій і процесів призначення.
Конфіденційність і захист даних біометрії особового складу
Військові біометричні дані — серед найчутливіших персональних даних, які опрацьовує оборонна організація. Скомпрометований шаблон відбитка пальця чи райдужки неможливо відкликати й перевидати, як пароль — щойно противник володіє еталонним шаблоном, біометрична модальність для цієї особи скомпрометована назавжди. Засоби захисту даних мають відповідати цій чутливості.
Шифрування біометричних даних на тактичних пристроях
Кожен пристрій, що зберігає біометричні шаблони — станції реєстрації, портативні зчитувачі перевірки та локальні сервери біометричної бази даних — має шифрувати дані в спокої за AES-256 з ключами, якими керує апаратний модуль безпеки (HSM) або захищене середовище виконання (TEE). Ключі шифрування не можна зберігати у файлах конфігурації застосунку чи змінних середовища на пристрої. Ротацію ключів слід проводити щонайменше щорічно, а негайна ротація потрібна, якщо пристрій повідомлено як втрачений або захоплений. На тактичних пристроях на базі Android система Android Keystore надає сховище ключів на основі TEE, яке задовольняє цю вимогу на апаратному забезпеченні, валідованому за FIPS 140-2 Level 2.
Політика зберігання біометричних шаблонів
Строки зберігання біометричних шаблонів слід визначати в політиці управління даними та забезпечувати системою, а не покладатися на адміністративний процес. Стандартна практика:
- Центральна база даних — зберігати протягом служби плюс період після звільнення, визначений національним законодавством (зазвичай 7–10 років для військових записів).
- Тактичні портативні пристрої — автоматично вилучати кешовані шаблони через 24–72 години; потрібна повторна реєстрація, якщо пристрій був офлайн довше за період кешування.
- Журнали перевірки на блокпостах — зберігати записи рішень «збіг/немає збігу» (без самого шаблону) 90 днів для аудиту; далі вилучати.
- Шаблони списків спостереження для затриманих або ворожих комбатантів — регулюються окремими повноваженнями та графіком зберігання, який визначає юридичний радник театру воєнних дій.
Поводження з персональними даними за GDPR для коаліційних сил
Коли коаліційні сили з держав-членів ЄС беруть участь у спільних операціях, їхні біометричні дані особового складу підпадають під GDPR незалежно від місця опрацювання. На практиці це означає: слід визначити правову підставу опрацювання (зазвичай стаття 9(2)(g) — суттєвий суспільний інтерес, або еквіваленти національного права); права суб'єкта даних (доступ, видалення) мають бути враховані в архітектурі системи; а передача біометричних даних партнерам поза ЄС потребує рішення про адекватність, стандартних договірних умов або винятку за статтею 49. Система обліку має фіксувати правову підставу для кожного біометричного запису, громадянство суб'єкта даних та будь-які події транскордонної передачі, щоб перевірку відповідності GDPR можна було провести без відтворення історії опрацювання з розрізнених журналів.
На практиці найпростіший архітектурний підхід для коаліційних операцій — федерація біометричних баз даних за громадянством: кожна держава підтримує власну біометричну базу даних і опрацьовує лише своїх громадян; звіряння з базами партнерів за конкретними запитами перевірки відбувається за офіційною угодою про обмін даними з задокументованою правовою підставою, а не через злиту багатонаціональну базу, яка ускладнює кожну національну перевірку відповідності.