JDLM en LOGFAS Integratie voor Coalitie-Instandhoudings­planning

Coalitieoperaties staan of vallen met instandhouding. Een multinationale taakgroep kan tactisch briljant zijn en toch tot stilstand komen omdat brandstof niet op het juiste knooppunt arriveerde, omdat medische klasse VIII ongevolgd tussen twee nationale voorraden verschoof, of omdat het transportplan van één natie uitging van een weg die ingenieurs van een andere natie nog niet hersteld hadden. De kosten van slecht geplande multinationale instandhouding worden gemeten in verloren gevechtskracht — niet in spreadsheetfouten.

Het NAVO-antwoord op dit probleem is LOGFAS — de Logistics Functional Area Services suite — en een kleine constellatie van ondersteunende tools. Het Amerikaanse antwoord, met breder gezamenlijk en interagentie­bereik, is JDLM. In de praktijk moet elke coalitie-inzet beide integreren, plus de eigen ERP's van de deelnemende naties. Dit artikel is een engineering-walkthrough van hoe die integratie daadwerkelijk werkt, wat stukgaat en wat standhoudt.

Het Coalitie-Instandhoudings­probleem

Nationale legers federeren niet van nature. Elk draait zijn eigen ERP — SAP bij sommige, Oracle EBS bij anderen, IFS bij een paar, maatwerk-legacy-systemen bij meer dan toegegeven wordt. Elk heeft zijn eigen materiaalcatalogus, zijn eigen NSN-naar-lokale-mapping, zijn eigen transportschema, zijn eigen rubriceringsregels. Wanneer twee naties een gecombineerde gezamenlijke taakgroep oprichten, sluit niets hiervan automatisch aan.

De historische noodoplossing was LOGREP — het LOGistieke REPort — uitgewisseld als plat bestand op planningsconferenties. LOGREP werd de coalitiemunt: onvolmaakt, met verlies, maar overeengekomen. De Force List van een natie, gereedheid van activa, verbruiksprognose en bewegingsplan worden allemaal samengevat in LOGREP-entries die andere coalitie­partners kunnen lezen. Vandaag is LOGREP nog steeds de lingua franca, maar de uitwisseling is verschoven van papier en e-mail naar LOGFAS en de bijbehorende protocollen.

Het diepere probleem is dat nationale ERP's nooit zijn gebouwd om hun interne werking bloot te stellen aan een coalitie. Hun gegevens zijn gevoelig, hun schema's zijn commercieel vertrouwelijk en hun operators zijn niet bevoegd ze te publiceren. Federatie moet worden ontworpen — het ontstaat niet vanzelf.

Overzicht van LOGFAS-componenten

LOGFAS is niet één applicatie. Het is een suite, gedistribueerd door het NAVO Communications and Information Agency (NCIA), met vier componenten die van belang zijn voor elk integratieproject.

LOGREP is het gegevensmodel en de database. Het definieert de entiteiten — Force Modules, Holdings, Requirements, Stockpiles, Movement Requirements — en de relaties ertussen. Elke andere LOGFAS-component leest of schrijft LOGREP. Wanneer ingenieurs zeggen "integreren met LOGFAS", bedoelen ze bijna altijd "LOGREP-database-inhoud produceren of consumeren."

ADAMS (Allied Deployment and Movement System) is het planningsoppervlak. ADAMS verbruikt LOGREP, past een netwerk van routes, modi en transportmiddelen toe en produceert bewegingsplannen — wie beweegt wat, via welk transportmiddel, naar welk tussenliggend knooppunt, op welke dag. ADAMS is waar coalitieplancers hun uren doorbrengen tijdens de inzetfase.

EVE (Effective Visible Execution) is de uitvoeringsmonitorings­laag. Waar ADAMS plant, volgt EVE de actualiteit: waar het konvooi werkelijk is, of het vliegtuig daadwerkelijk vertrokken is, of de voorraad daadwerkelijk gearriveerd is. EVE is het dichtst bij een realtime beeld dat LOGFAS heeft, hoewel "realtime" in logistiek vaak betekent "posities van vandaag gerapporteerd om 0700."

SDM (System Data Management) is de administratieve ruggengraat — gebruikers, rollen, vrijgeefsprotocol, databasesynchronisatie, catalogusbeheer. SDM is onzichtbaar voor plancers en centraal voor integrateurs. Elke cross-database-synchronisatie, elke catalogusharmonisatie, elke vrijgeefregel leeft hier.

De vier werken samen via de gedeelde LOGREP-database. Een wijziging aan een Force Module in één component verschijnt bij de volgende sync in de anderen. De meeste integratieprojecten richten zich direct op het LOGREP-schema en behandelen ADAMS en EVE als weergaven over een gedeeld substraat.

JDLM (Joint Deployment and Logistics Model)

JDLM is het modelleringssysteem van het Amerikaanse Transportation Command (USTRANSCOM) voor gezamenlijke inzet en instandhouding. Waar LOGFAS zich richt op coalitie­planning, richt JDLM zich op Amerikaanse gezamenlijke en interagentie­bewegingen — en in toenemende mate op de modellering die nodig is om alternatieve handelwijzen te evalueren onder beperkingen.

JDLM verbruikt een andere upstream: TPFDD (Time-Phased Force and Deployment Data)-feeds van JOPES en zijn opvolger­systemen, JDLM-native modelleringsinputs van plancers en inlichtingen­overlays. Zijn outputs zijn inzetopties gescoord op tijd, moduscapaciteit en risico. Het interoperabiliteitsverhaal met LOGFAS is niet symmetrisch — de twee systemen wisselen geen databases uit. Het is vertaling. Een Amerikaans plan gemodelleerd in JDLM moet worden heruitgedrukt als LOGREP-compatibele bewegings- en holdings-records zodat coalitie­partners het kunnen inladen.

In de praktijk betekent dit dat een vertaalknooppunt tussen hen in zit — een kleine service die JDLM-exports leest, veldmappingen toepast, rubriceringsregels toepast en de LOGREP-vormige output schrijft naar een fase die LOGFAS kan ophalen. Elke coalitie-inzet waarbij de VS betrokken zijn, draait een versie van dit knooppunt.

STANAG 2406-familie

De logistieke rapportage-STANAG's liggen onder alles. STANAG 2406 omvat logistieke rapportage in brede zin, en de gerelateerde STANAG's in de 2400-reeks definiëren specifieke uitwisselings­formaten — brandstofrapportage, munitierapportage, slachtoffer- en medische logistieke rapportage, transport­bewegings­rapportage.

De MEDLOG-uitbreiding — medische logistiek — is het onderdeel dat teams het vaakst onderschatten. Medische klasse VIII heeft andere houdbaarheidregels, andere temperatuurvereisten, andere cross-nationale vrijgaveprofielen en andere rapportage­cadences dan algemene bevoorrading. Een LOGFAS-integratie die klassen I tot V schoon verwerkt, zal nog steeds falen bij de audit van klasse VIII als MEDLOG niet correct gemodelleerd is. Plan ervoor vanaf de eerste sprint.

De STANAG's definiëren het draadformaat. Implementeerders moeten ze behandelen als het contract: alles wat het platform produceert, moet een round-trip door een STANAG-conform exportformaat kunnen maken zonder verlies. Deze regel alleen al vangt meer bugs dan enige andere discipline.

Integratiepatronen

Drie patronen domineren.

Pull (poll LOGREP). Een extern systeem peilt een LOGREP-replica op een schema — elke vijftien minuten, elk uur — vergelijkt met de laatste snapshot en handelt naar aanleiding van wijzigingen. Pull is eenvoudig, voorspelbaar en gemakkelijk te beheren. Het is ook verliesgevend: als een record wordt aangemaakt en verwijderd tussen polls, ziet de poller het nooit. Voor planningsgegevens — die veranderen op conferentiecadence, niet per seconde — is pull correct.

Push (event stream naar LOGFAS). Upstream systemen zenden wijzigings­events uit — een voorraad bijgewerkt, een beweging uitgevoerd — naar een message bus, en een LOGFAS-adapter verbruikt ze en schrijft ze in LOGREP. Push is dichter bij realtime en verliesvrij, maar vereist een robuuste message queue en zorgvuldige idempotentie. Voor uitvoeringsgegevens is push correct.

Staging (vertaalknooppunt met rubriceringspoort). Het canonieke coalitie-ontwerp. Nationale ERP's publiceren naar een nationaal stadium. Een vertaalknooppunt — eigendom van het integratieteam, vaak air-gapped van de upstream — leest uit het stadium, past veldmappingen toe, past vrijgaveregels toe en schrijft naar een coalitie-zijdige LOGREP. Het vertaalknooppunt is het enige snoerpunt waar rubricering, vrijgave en schema samenkomen. Bouw het expliciet. Laat het niet organisch ontstaan.

Rubricering en Vrijgave

Nationale logistieke gegevens zijn standaard nationaal. NAVO RESTRICTED is de ondergrens waarop de meeste coalitie-uitwisselingen zitten, maar hetzelfde record kan vrijgegeven zijn voor NAVO maar niet voor een specifieke partnernationale, of vrijgegeven voor één missie maar niet voor een andere. Vrijgave is geen rubricering — het is de orthogonale as die bepaalt wie wat ziet binnen een gegeven rubriceringsniveau.

Het patroon dat werkt is saneren-bij-uitgang. Elk record draagt een vrijgavevector — een set van naties en missies waarvoor het is goedgekeurd. Het vertaalknooppunt weigert elk record te schrijven waarvan de vrijgavevector de bestemming niet omvat. Velden die nationaal gevoelig zijn (specifieke chargenummers, leveranciersnamen, eindartikelserienummers) worden verwijderd of gehasht voordat het record de poort passeert. Coalitie-interoperabiliteitsdiscipline vereist dat dit in code wordt afgedwongen, niet in beleid. Beleid faalt onder operationeel tempo.

De poort logt ook. Elk record dat passeert, elk geweigerd record, elk gesaneerd veld — gelogd met herkomst. Vrijgave-audits komen. Wees er klaar voor.

Federeren van Nationale ERP's in LOGFAS

SAP, Oracle EBS, IFS en Maximo zijn de vier upstream bronnen die we het vaakst zien. Elk mapt anders naar LOGREP.

SAP MM (Materials Management) draagt holdings en verbruik met hoge getrouwheid maar gebruikt nationale materiaalkodes — het mappen hiervan naar NSN's is de helft van het integratiewerk. De mapping is zelden één-op-één; verwacht een samengestelde cross-walk-tabel onderhouden door de materiaalautoriteit. Defensie ERP-integratiepatronen zijn hier direct van toepassing.

Oracle EBS Inventory en IFS Supply hebben vergelijkbare vormen maar verschillende veldsemantiek — "voorhanden" in het ene is "beschikbaar" in het andere, met reserveringen en onderweg-behandeld inconsistent. Lees de velddefinities, niet de veldnamen.

Maximo, zwaar gebruikt voor vlootonderhoud, levert gereedheidsgegevens — voertuigstatus, uitgesteld onderhoud, missie-beschikbaarheidspercentages. Maximo voedt de gereedheidskolommen van een LOGREP Force Module-record. Verkeerd modelleer gereedheid en het coalitieplan is gebouwd op fictie.

Voor de pijplijn is change-data-capture (CDC) de juiste vorm. Voer CDC uit tegen de ERP, materialiseer een nationale projectie, transformeer naar LOGREP-vorm, poort op vrijgave, schrijf over. Batchreplicatie breekt op randgevallen; de per-record-discipline van CDC vangt ze.

Operationele Lessen

De oefeningen Steadfast Defender en Trident Juncture hebben coalitielogistiek end-to-end stress-getest op schalen dicht bij echte oorlogsvoering. Het patroon van falen is consistent.

Wat het eerst stukgaat is de catalogus. De lokale catalogus van een natie wijkt af van de overeengekomen NSN-cross-walk — een nieuw artikel treedt in dienst, de cross-walk-update wordt uitgesteld, en van de ene op de andere dag produceert de LOGREP-feed "onbekend materieel"-rijen die downstream-verbruikers stilzwijgend laten vallen. Bouw catalogusdrift­detectie in de pijplijn. Alarmeer er binnen dezelfde dienst op.

Wat het tweede stukgaat is tijd. LOGREP-tijdstempels worden gerapporteerd in lokale tijd zonder zone in oudere feeds, in UTC in nieuwere en in missiontijd in sommige operationele contexten. Een enkele integratie die deze vermengd, produceert bewegingsplannen waarbij konvooien aankomen voor ze vertrekken. Normaliseer naar UTC bij inladen. Vertrouw nooit een wandklok-tijdstempel.

Wat het derde stukgaat is vrijgave. Een veld dat gisteren vrijgegeven was, wordt vandaag nationaal gevoelig — een leveranciersnaam, een chargenummer, een routedetail. Als vrijgave hard-gecodeerd is in de vertaalregels in plaats van per-record te worden meegenomen, wordt elke wijziging een code-release. Maak vrijgave data, geen code.

Wat het vierde stukgaat is de mens in de lus. ADAMS-plancers en EVE-operators werken dienstrotaties, en de overdracht tussen diensten is waar de meeste datakwaliteitsregressies binnenkomen. Een beweging wordt gedeeltelijk bijgewerkt door de uitgaande dienst, de inkomende dienst gaat ervan uit dat het record definitief is, en downstream-verbruikers laden een half-geschreven plan in. De oplossing is geen training. De oplossing is het afdwingen van record-niveau-atomiciteit op de LOGREP-grens — gedeeltelijke schrijfopdrachten worden geweigerd, volledige updates slagen. Duw de beperking in de schemalagen waar dienstvermoeidheid het niet kan omzeilen.

Wat standhoudt over oefeningen heen is het team dat het vertaalknooppunt end-to-end beheert — schema, mapping, vrijgave, poort, auditlog. Dat eigenaarschap kan niet worden opgesplitst over naties of aannemers zonder dat de naden het storingsoppervlak worden. Één team, één poort, één verantwoordelijke eigenaar. Al het overige is bijzaak.

De discipline die standhoudt is datakwaliteit. Coalitielogistiek wordt niet gered door een slimmere optimizer. Het wordt gered door schone catalogi, eerlijke gereedheid, getrouwe tijdstempels en vertaalpoorten die weigeren te liegen. Bouw daarvoor en de rest volgt. Voor het bredere operationele beeld behandelen onze defensie supply chain software- en predictief-onderhoud-artikelen aangrenzend terrein.