Software de deschidere a teatrului și management al susținerii

Deschiderea teatrului de operații este cea mai intensă fază logistică a oricărui desfășurare majoră de forțe. Înainte ca prima unitate de luptă să poată fi angajată în operații, un volum enorm de personal, echipamente, combustibil, muniție și stocuri de susținere trebuie să curgă printr-un set limitat de puncte de intrare strategice — porturi maritime și aeroporturi — într-un teatru care poate avea infrastructură limitată, spațiu aerian contestat și un adversar care încearcă activ să perturbe construcția forței. Software-ul care gestionează acest flux determină dacă o forță sosește pregătită să lupte sau sosește fragmentat, insuficient aprovizionată și vulnerabilă operațional.

Software-ul de management al susținerii în teatrul de operații nu este un ERP comercial îmbrăcat în camuflaj. Trebuie să gestioneze manifestarea mărfurilor și debitul la porturile de debarcație unde sute de containere sosesc zilnic, să planifice o rețea de distribuție care nu există la începutul operațiunilor, să arbitreze între modelele de logistică push și pull pe măsură ce situația operațională evoluează și să ofere vizibilitate la toate eșaloanele unui teatru care poate acoperi sute de kilometri. Acest articol descrie arhitectura sistemelor software capabile să gestioneze fiecare fază a acestei provocări.

Logistica deschiderii teatrului: de la navă la poziția de luptă

Deschiderea teatrului cuprinde recepția, gruparea, mișcarea înaintată și integrarea (RSOI) forțelor și aprovizionărilor lor de susținere într-un teatru operațional. Fiecare fază impune cerințe distincte sistemului informațional de susținere.

Recepția are loc la portul de debarcație — portul maritim (SPOD) sau aeroportul (APOD) unde liftul strategic livrează forța. La un port maritim, navele roll-on/roll-off (RO/RO) descarcă vehicule cu roți și echipamente cu șenile direct pe chei; navele cu containere descarcă cutiile ISO prin macarale în parcurile de sortare. La un aeroport, aeronavele C-17, C-130 sau aeronavele aliate de transport parchează pe platforme pentru descărcare rapidă înainte ca următorul val de aeronave să necesite spațiul. Recepția este limitată de numărul de dane, capacitatea macaralelor, parcarea pe platforme și ratele de vămuire — toți parametri pe care software-ul de susținere trebuie să îi modeleze ca parametri de capacitate.

Gruparea constă în adunarea mărfurilor descărcate în zona de grupare a portului în așteptarea mișcării înaintate. Vehiculele care sosesc fără echipaje, containerele care sosesc înainte de unitatea mamă și echipamentele care așteaptă inspecția vamală se acumulează în zona de grupare. Managementul deficitar al grupării — spațiu insuficient, responsabilitate neclară, urmărire inadecvată — creează congestionarea portului care a întârziat istoric deschiderile de teatru cu zile sau săptămâni. Software-ul care urmărește fiecare unitate de încărcătură prin zona de grupare cu RFID sau scanare de coduri de bare și care semnalează încălcările timpului de staționare este instrumentul principal pentru prevenirea congestionării grupării.

Mișcarea înaintată este mișcarea prin convoi, cale ferată sau aer a mărfurilor grupate de la POD la zona de adunare tactică (TAA) unde unitățile se consolidează înainte de angajarea în operații. Mișcarea înaintată este planificată pe baza secvenței TPFDD (Time-Phased Force and Deployment Data) — unitățile cu angajamente operaționale mai timpurii au prioritate pentru mișcarea înaintată indiferent de momentul în care marfa lor ajunge la port.

Integrarea este faza finală, în care echipamentele, muniția, combustibilul și rațiile care au sosit separat sunt reunite cu unitățile mamă în TAA, astfel încât unitatea să poată efectua inspecții de pregătire și să se declare disponibilă pentru operații.

Cerința software critică care acoperă toate cele patru faze este un singur registru pentru fiecare TCN (Transportation Control Number) — identificatorul DoD pentru o unitate de încărcătură — care urmărește starea acestuia prin pipeline-ul RSOI. Fără aceasta, Comandamentul de Susținere al Teatrului nu poate răspunde la cea mai fundamentală întrebare: unde se află marfa X și când va ajunge la unitatea Y?

Software de management al portului de debarcație

Software-ul de management al portului de debarcație gestionează faza de recepție la punctul de intrare. Funcțiile sale principale sunt manifestarea mărfurilor, urmărirea debitului, urmărirea RFID și managementul materialelor periculoase și vamal.

Manifestarea mărfurilor preia manifestul de marfă al navei sau al aeronavei, îl compară cu TPFDD și creează un registru TCN pentru fiecare unitate de încărcătură. Integrarea manifestului trebuie să gestioneze realitatea că manifestele sosesc în mai multe formate: încărcăturile etichetate cu RFID produc liste TCN automate prin sistemul ITV (In-Transit Visibility); marfa mai veche poate sosi cu manifeste pe hârtie care necesită introducere manuală a datelor. Software-ul trebuie să gestioneze ambele variante fără a crea înregistrări TCN duplicate.

Un registru TCN tipic în sistemul de management POD conține:

{
  "tcn":          "T2AABC1234567",
  "unit_id":      "1-68AR",
  "nsn":          "2350-01-523-5947",
  "description":  "TANK, COMBAT, FULL TRACKED: M1A2 SEPv3",
  "quantity":     1,
  "unit_of_issue":"EA",
  "gross_weight_kg": 62000,
  "hazmat_class": null,
  "tpfdd_arrival": "2026-06-24T06:00:00Z",
  "actual_arrival": "2026-06-24T08:14:00Z",
  "rsoi_state":   "STAGING",
  "staging_area": "YARD-BRAVO",
  "staging_since": "2026-06-24T10:30:00Z",
  "priority":     1,
  "onward_destination": "TAA-NORTH"
}

Urmărirea debitului măsoară rata de procesare efectivă a portului față de rata planificată din TPFDD. Dacă planul necesită 5.000 de tone scurte pe zi să treacă prin SPOD pentru a respecta termenul de închidere a forței, iar debitul efectiv este de 3.800 de tone pe zi, software-ul trebuie să evidențieze această abatere și să proiecteze întârzierea rezultată a închiderii forței, astfel încât Comandamentul de Susținere al Teatrului să poată lua măsuri corective — adăugarea de ture la macarale, solicitarea de active suplimentare de camioane sau ajustarea secvențelor de prioritate ale unităților.

Urmărirea RFID la POD utilizează portaluri interogator RFID UHF pasiv (ISO 18000-6C, EPC Gen 2) instalate la punctele critice ale portului. Fiecare unitate de încărcătură etichetată — container, paletă sau vehicul — este citită automat când trece prin zonele de descărcare a macaralelor, porțile zonei de grupare și porțile de ieșire din port. Citirea portalului generează un eveniment cu marcaj temporal care avansează starea RSOI a TCN în baza de date fără introducere manuală de date. TCN-urile reziduale necitite (cele ale căror etichete au fost deteriorate sau citite de o defecțiune a portalului) sunt verificate cu cititorul portabil la sfârșitul fiecărui schimb.

Procesarea HAZMAT și vamală adaugă un flux de lucru paralel: containerele cu marfă de Clasă 1 (explozivi), Clasă 3 (lichide inflamabile) sau Clasă 9 (diverse materiale periculoase) necesită zone de grupare segregate și aprobări speciale de manipulare. Software-ul aplică asignări ale zonelor de grupare pe baza clasei de materiale periculoase și generează documentația HAZMAT necesară pentru autoritățile vamale ale statului gazdă.

Planificarea rețelei de distribuție

Odată ce marfa depășește zona de grupare a portului, trebuie să se deplaseze printr-o rețea de distribuție pe care comandamentul de susținere al teatrului o construiește în paralel cu sosirea forței operaționale. Rețeaua de distribuție conectează POD la punctele de aprovizionare înaintate printr-o serie de noduri logistice intermediare, fiecare conținând stocuri adecvate eșalonului său.

Arhitectura standard de distribuție a teatrului utilizează trei noduri la nivel de eșalon:

Nod	Eșalon	Capacitate tipică	Clase principale de aprovizionare
Theater Distribution Base (TDB)	Teatru	30–90 zile	I, II, III, IV, V, VIII, IX
Combat Sustainment Support Bn (CSSB)	Divizie	7–15 zile	I, III, V, IX cerere ridicată
Brigade Support Bn (BSB)	Brigadă	3–5 zile	I, III, V încărcături prescrise

Transport de linie vs transport local este decizia fundamentală de planificare a distribuției la fiecare limită de eșalon. Transportul de linie este mișcarea în vrac de la depozitul teatrului la zona de sprijin a diviziei folosind active dedicate de camioane de linie (PLS flat-rack, HET pentru echipamente grele). Transportul local este livrarea finală din zona de sprijin a diviziei spre punctele de aprovizionare ale brigăzilor folosind transportul organic al unităților. Activele de transport de linie sunt rare și trebuie programate pentru a maximiza tone-mile pe vehicul pe zi; transportul local este limitat de densitatea de camioane organice ale unităților sprijinite și de considerațiile de securitate a rutelor tactice.

Software-ul de planificare a rețelei de distribuție modelează rutele de transport între noduri ca un graf orientat cu atribute de capacitate și timp de deplasare. Modelul de rețea permite software-ului să calculeze:

# Verificarea capacității de distribuție (pseudo-cod)
def check_route_capacity(route_id, planned_tons_per_day):
    route = network.get_route(route_id)
    constraints = [
        route.bridge_classification,    # MLC pentru traversare
        route.surface_type,             # MSR, ASR, drum de pământ
        route.current_status,           # DESCHIS / RESTRICȚIONAT / ÎNCHIS
        route.max_tons_per_day          # capacitate de control al traficului
    ]
    available_capacity = min(
        c.effective_capacity() for c in constraints
    )
    utilization = planned_tons_per_day / available_capacity
    if utilization > 0.85:
        raise CapacityWarning(
            f"Ruta {route_id}: {utilization:.0%} din capacitate."
            " Necesară rutare alternativă."
        )
    return utilization

Deciziile de poziționare BSA, CSA și ASA — unde să plaseze nodurile logistice pe măsură ce situația tactică evoluează — sunt informate de analiza de sensibilitate a modelului de rețea. Mutarea unui BSA cu 20 km înainte poate reduce timpii de transport local, dar îi crește vulnerabilitatea și necesită un nou segment de transport de linie. Software-ul ar trebui să permită planificatorilor să evalueze poziții alternative ale nodurilor prin actualizarea coordonatelor nodurilor și recalcularea modelului de cost al rețelei, evidențiind compromisurile în timpul de livrare, distanța rutei și utilizarea vehiculelor înainte ca pozițiile să fie confirmate.

Modele de susținere push vs pull

Alegerea între logistica push și pull nu este binară — este o politică dinamică care se schimbă în funcție de Clasa de aprovizionare, de faza operațiunii și de maturitatea rețelei de distribuție. Software-ul de susținere al teatrului trebuie să implementeze ambele modele și să sprijine tranziția între ele.

Logistica push trimite pachete pre-configurate de provizii către unități pe bază programată fără a solicita unităților să depună cereri. În timpul deschiderii teatrului, push este implicit pentru Clasele I (rații), III(B) (petrol în vrac) și apă, deoarece sistemul de aprovizionare al unității poate să nu fie încă operațional, comunicațiile radio pot fi limitate, iar ratele de consum standard sunt suficient de previzibile pentru a planifica stocuri pre-poziționate. O listă de încărcătură prescrisă (PLL) pentru un batalion mecanizat specifică cantitățile standard de piese de schimb Clasa IX; un pachet push pentru un batalion nou sosit este construit din această PLL și expediat pe măsură ce unitatea ajunge în TAA.

Logistica pull este orientată pe cerere: unitățile depun cereri pentru articole specifice, iar sistemul de aprovizionare completează și expediază pe baza acestor cereri. Pull este mai precis decât push — răspunde la consumul efectiv, nu la consumul estimat — dar necesită sisteme de comunicații funcționale și o structură administrativă de aprovizionare la nivelul unității. Pull devine modelul dominant odată ce forța este stabilită și sistemul de distribuție a atins operațiunile de regim staționar.

Software-ul de lanț de aprovizionare pentru apărare trebuie să implementeze push și pull ca fluxuri de lucru separate, dar integrate. Pachetele push sunt planificate la nivelul comandamentului de susținere și expediate fără acțiunea unității; cererile pull își au originea la nivelul unității și circulă în sus prin sistemul de aprovizionare. O abordare hibridă — push pentru pachetul zilnic Clasa I în mod automat, dar cereri pull necesare pentru piesele de schimb Clasa IX — este practica standard în majoritatea planurilor de operații ale teatrului.

Funcționalitatea software critică pentru gestionarea tranziției push-to-pull este un mecanism de urmărire a consumului care detectează când consumul efectiv Clasa IX diverge de ipotezele pachetului push. Dacă unitățile extrag piese de schimb la de două ori rata planificată, cantitatea pachetului push este insuficientă și diferența trebuie acoperită prin cereri pull reactive. Software-ul trebuie să evidențieze automat această divergență, fără a se baza pe analiza manuală a ofițerului de aprovizionare.

Controlul fluxului de susținere: tabloul comun de operații logistice al teatrului

Tabloul comun de operații logistice al teatrului (LCOP) este afișajul integrat care oferă Comandamentului de Susținere al Teatrului vizibilitate asupra întregului flux de susținere — de la marfa aflată încă la bordul navelor pe mare, prin POD, prin rețeaua de distribuție, până la zilele de aprovizionare la nivel de unitate. Este instrumentul principal pentru controlul fluxului: identificarea locului unde pipeline-ul de susținere este congestionat și redirecționarea activelor pentru a elimina congestionarea.

Platforma de vizibilitate a logisticii militare care stă la baza LCOP integrează date din mai multe surse:

• Sistemul ITV (In-Transit Visibility) — date de urmărire RFID și GPS pentru toate activele etichetate din pipeline-ul de distribuție
• Sistemul de debit POD — debitul zilnic al portului, rata de umplere a zonei de grupare, timpii de staționare
• Rapoarte de stare a aprovizionării unităților — zilele de aprovizionare disponibile pe Clasă, trimise zilnic de secțiile S4 ale unităților
• Starea activelor de distribuție — disponibilitatea camioanelor, ratele de utilizare PLS și HET
• Starea rutelor — rute deschise/restricționate/închise, actualizate din COP și rapoarte de degajare a rutelor

LCOP prezintă aceste date pe un afișaj geospațial cu simboluri specifice logisticii (simboluri logistice MIL-STD-2525 pentru puncte de aprovizionare, zone de întreținere, facilități medicale) și un set de straturi de stare a aprovizionării care codifică cu culori locațiile unităților în funcție de zilele de aprovizionare — verde pentru stoc adecvat, chihlimbar pentru marginal, roșu pentru lipsă critică. Personalul J4 poate vedea dintr-o privire care unități sunt expuse riscului de eșec al susținerii și care rute de distribuție sunt disponibile pentru a le ajunge.

Acțiunile de control al fluxului luate prin LCOP includ: reprioritizarea curselor de camioane pentru a sprijini unitățile cu lipsuri critice, devierea mărfurilor în tranzit de pe o rută congestionată pe o rută alternativă, solicitarea aprovizionării aeriene (CH-47 sau sarcina suspendată UH-60) pentru a ajunge la unitățile tăiate de la distribuția terestră și ajustarea programului de pachete push pentru a evita depășirea capacității de debit zilnic al sistemului de distribuție.

Integrarea cu sistemele de mobilitate strategică

Software-ul de susținere al teatrului nu funcționează izolat — primește planul de desfășurare de la sistemele strategice și le transmite înapoi date de execuție. Punctele cheie de integrare sunt JOPES, TCAIMS-II și LOGFAS pentru partenerii din coaliție.

JOPES (Joint Operation Planning and Execution System) este sursa autorizată pentru TPFDD — secvența de desfășurare care specifică ce unități se mișcă când, cu ce echipamente, pe ce lift strategic. Software-ul de susținere al teatrului preia TPFDD pentru a construi programul de sosire așteptat la POD. Când sosirile efective deviază de la TPFDD (nave întârziate de vreme, aeronave deviate), sistemul calculează impactul asupra datei de disponibilitate operațională a unității și îl semnalează pentru evaluarea J4.

TCAIMS-II (Transportation Coordinator's Automated Information for Movements System II) gestionează funcția de control al mișcării: atribuirea liftului strategic unităților, gestionarea autorizațiilor de convoi și urmărirea cererilor de mișcare până la execuție. Software-ul de susținere al teatrului se interfațează cu TCAIMS-II pentru a primi autorizațiile de convoi aprobate și pentru a raporta finalizarea efectivă a convoiului, închizând bucla de control al mișcării.

LOGFAS (Logistics Functional Area Services) este echivalentul din coaliție pentru aliații europeni. Standardele de raportare logistică pe care LOGFAS le implementează utilizează modele de date diferite față de tranzacțiile DLMS americane — numere de stoc NATO versus NSN-uri, convenții diferite de unitate de emisiune și formate de mesaje diferite. Un sistem de susținere al teatrului de coaliție trebuie să implementeze un strat de traducere care convertește între formatele de tranzacții logistice americane (DLMS 856 notificare de expediere anticipată, DLMS 832 catalog de prețuri/vânzări) și echivalentele LOGFAS. Stratul de traducere trebuie să păstreze echivalența semantică — nu doar maparea câmpurilor, ci interpretarea corectă a cantității, unității de emisiune și convențiilor de clasificare între partenerii aliați.

# Comparația sosirii TPFDD vs efectivă
SELECT
    t.tcn,
    t.unit_id,
    t.tpfdd_arrival::date          AS planned_arrival,
    t.actual_arrival::date         AS actual_arrival,
    (t.actual_arrival - t.tpfdd_arrival)
        / INTERVAL '1 day'        AS variance_days,
    t.priority,
    t.onward_destination
FROM tcn_records t
WHERE t.rsoi_state IN ('POD_ARRIVED','STAGING')
  AND t.actual_arrival IS NOT NULL
ORDER BY ABS(
    EXTRACT(EPOCH FROM (t.actual_arrival - t.tpfdd_arrival))
) DESC
LIMIT 50;

Metrici de susținere și raportarea capacității operaționale

Comandamentul de Susținere al Teatrului raportează zilnic personalului Joint Logistics (J4) despre starea de susținere a teatrului. Aceste rapoarte sunt mecanismul principal prin care comandantul operațional evaluează dacă baza de susținere poate sprijini operațiunile planificate. Generarea lor manuală din surse de date disparate — jurnale de debit al portului, mesaje de stare a aprovizionării unităților, rapoarte de finalizare a convoaielor — este consumatoare de timp și predispusă la erori. Software-ul de susținere al teatrului automatizează această generare de rapoarte din date actualizate continuu.

Metricile critice de susținere sunt:

Rata de debit a portului — tone scurte eliminate din POD pe zi, măsurate față de rata planificată necesară pentru a respecta închiderea forței. Abaterea sub plan se acumulează: un port care funcționează la 80% din debitul planificat timp de cinci zile acumulează un deficit echivalent cu marfa unui vas complet, întârziind închiderea forței cu un întreg ciclu de descărcare a unui vas.

Timpul de răspuns la aprovizionare (SRT) — timpul scurs de la depunerea cererii de aprovizionare a unității până la disponibilitatea articolului la punctul de aprovizionare al unității. Descompunerea SRT — separarea timpului de procesare a cererii, a timpului de emitere, a timpului de transport și a timpului de recepție — identifică care componentă a lanțului de livrare constituie blocajul. Un timp lung de transport poate indica active de camioane insuficiente; un timp lung de emitere poate indica un punct de aprovizionare care funcționează fără management automatizat al depozitului.

Umplerea pipeline-ului pe Clasă de aprovizionare — cantitatea totală din fiecare Clasă de aprovizionare aflată în prezent în pipeline-ul de distribuție (în tranzit, dar neajunsă încă la o unitate). Umplerea pipeline-ului determină câte rezerve există între poziția curentă disponibilă și o lipsă. O umplere a pipeline-ului de mai puțin de cinci zile pentru Clasa III(P) (petrol ambalat) la nivelul BSA indică risc în timpul operațiunilor de tempo ridicat care ar putea depăși ciclurile de livrare.

Zilele de aprovizionare (DOS) disponibile — metrica de susținere cel mai frecvent raportată, calculată per unitate și per Clasă de aprovizionare din raportul zilnic de stare a aprovizionării al unității. Comandamentul de susținere solicită fiecărei unități să mențină un prag minim DOS (de obicei 3 DOS pentru Clasele I și III la nivel de companie, 5 DOS la nivel de batalion) — unitățile sub prag generează acțiuni automate de reaprovizionare.

Raportul automatizat de estimare a susținerii agregă aceste metrici cu linii de tendință și generează un raport zilnic structurat:

ESTIMARE SUSȚINERE TEATRU — 24 IUN 2026 / 0600L
─────────────────────────────────────────────────────
STARE POD (SPOD ALPHA)
  Debit (ultimele 24h):  4.840 ST   [Plan: 5.200 ST  ▼ −7%]
  Umplere zonă grupare:   68% / 100% capacitate
  Marfă staționare > 24h: 142 TCN-uri   ← ACȚIUNE NECESARĂ
  Nave în port:           3 (USNS Gilliland, ARC Endurance, MV Resolve)
  Nave la ancoră:         1 (ETA danǎ 25 IUN 0200L)

PIPELINE DISTRIBUȚIE
  Clasa I (Rații):       4,2 DOS medie pe BCT-uri   [Verde]
  Clasa III(B) (Vrac):   5,1 DOS la TDB; 3,8 DOS BSB   [Chihlimbar]
  Clasa V (Muniție):     Umplere pipeline 8.500 ST   [Verde]
  Clasa IX (Piese):      SRT mediu 38h   [Plan: 24h  ▼ +58%]

RUTE DE DISTRIBUȚIE
  MSR IOWA:      DESCHIS (confirmat 0400L)
  ASR COLUMBIA:  RESTRICȚIONAT (reparație pod, max MLC 50)
  ASR DECKER:    DESCHIS

UNITĂȚI LA RISC (< 3 DOS pe orice Clasă):
  2-7 CAV (Clasa III): 2,1 DOS — reaprovizionare de urgență trimisă
─────────────────────────────────────────────────────

Alerta de staționare a mărfii din exemplul de mai sus — 142 TCN-uri în grupare de mai mult de 24 de ore — ar fi invizibilă într-un sistem manual până când un inventar fizic ar descoperi marfa blocată. În operațiunile POD gestionate de software, alerta apare în câteva minute de la depășirea pragului de staționare, permițând ofițerului OIC al portului să investigheze și să elimine blocajul înainte ca acesta să se agraveze într-o congestionare generală a zonei de grupare.