JDLM- und LOGFAS-Integration für die Koalitions-Nachschubplanung

Koalitionsoperationen leben oder sterben am Nachschub. Eine multinationale Einsatzgruppe kann taktisch brillant sein und dennoch zum Stillstand kommen, weil Kraftstoff nicht am richtigen Knoten ankam, weil medizinische Klasse VIII zwischen zwei nationalen Beständen unregistriert verschoben wurde oder weil der Transportplan einer Nation eine Straße voraussetzte, die die Pioniere einer anderen Nation noch nicht instand gesetzt hatten. Der Preis schlecht geplanten multinationalen Nachschubs bemisst sich in verlorener Kampfkraft — nicht in Tabellenkalkulationsfehlern.

Die Antwort der NATO auf dieses Problem ist LOGFAS — die Logistics Functional Area Services-Suite — sowie eine kleine Konstellation unterstützender Werkzeuge. Die US-Antwort, mit breiterer streitkräfteübergreifender und ressortübergreifender Reichweite, ist JDLM. In der Praxis muss jeder Koalitionseinsatz beides integrieren, zuzüglich der eigenen ERP-Systeme der teilnehmenden Nationen. Dieser Artikel ist ein Engineering-Leitfaden dazu, wie diese Integration tatsächlich funktioniert, was bricht und was hält.

Das Problem des Koalitions-Nachschubs

Nationale Armeen föderieren sich nicht von selbst. Jede betreibt ihr eigenes ERP — in einigen SAP, in anderen Oracle EBS, in wenigen IFS, in mehr als zugegeben proprietäre Altsysteme. Jede hat ihren eigenen Materialkatalog, ihre eigene NSN-zu-Lokal-Zuordnung, ihr eigenes Transport-Schema, ihre eigenen Klassifizierungsregeln. Wenn zwei Nationen eine kombinierte streitkräftegemeinsame Einsatzgruppe aufstellen, fügt sich nichts davon automatisch zusammen.

Die historische Notlösung war LOGREP — der LOGistics REPort — als Flachdatei auf Planungskonferenzen ausgetauscht. LOGREP wurde zur Koalitionswährung: unvollkommen, verlustbehaftet, aber vereinbart. Die Force List, der Bereitschaftsstatus, die Verbrauchsprognose und der Bewegungsplan einer Nation kollabieren alle in LOGREP-Einträge, die andere Koalitionspartner lesen können. Heute ist LOGREP noch immer die Lingua franca, aber der Austausch ist von Papier und E-Mail in LOGFAS und die Protokolle drumherum gewandert.

Das tiefere Problem ist, dass nationale ERPs nie dafür gebaut wurden, ihre Innereien einer Koalition offenzulegen. Ihre Daten sind sensibel, ihre Schemata sind kommerziell vertraulich, und ihre Bediener sind nicht autorisiert, sie zu veröffentlichen. Föderation muss konstruiert werden — sie geschieht nicht.

LOGFAS-Komponententour

LOGFAS ist nicht eine Anwendung. Es ist eine Suite, vertrieben von der NATO Communications and Information Agency (NCIA), mit vier Komponenten, die für jedes Integrationsprojekt von Bedeutung sind.

LOGREP ist das Datenmodell und die Datenbank. Es definiert die Entitäten — Force Modules, Holdings, Requirements, Stockpiles, Movement Requirements — und die Beziehungen zwischen ihnen. Jede andere LOGFAS-Komponente liest oder schreibt LOGREP. Wenn Ingenieure sagen „mit LOGFAS integrieren", meinen sie fast immer „LOGREP-Datenbankinhalte produzieren oder konsumieren".

ADAMS (Allied Deployment and Movement System) ist die Planungsoberfläche. ADAMS konsumiert LOGREP, wendet ein Netz aus Routen, Verkehrsträgern und Transportmitteln an und produziert Bewegungspläne — wer bewegt was, mit welchem Verkehrsträger, zu welchem Zwischenknoten, an welchem Tag. ADAMS ist dort, wo Koalitionsplaner während der Verlegephase ihre Stunden verbringen.

EVE (Effective Visible Execution) ist die Ausführungs-Überwachungsschicht. Wo ADAMS plant, verfolgt EVE Ist-Werte: wo der Konvoi tatsächlich ist, ob das Luftfahrzeug tatsächlich abgehoben hat, ob der Bestand tatsächlich angekommen ist. EVE ist das, was LOGFAS einem Echtzeitbild am nächsten kommt, auch wenn „Echtzeit" in der Logistik oft „die heutigen Positionen, gemeldet um 07:00 Uhr" bedeutet.

SDM (System Data Management) ist das administrative Rückgrat — Benutzer, Rollen, Freigabefähigkeit, Datenbanksynchronisation, Katalogverwaltung. SDM ist für Planer unsichtbar und für Integratoren zentral. Jede datenbankübergreifende Synchronisation, jede Katalogharmonisierung, jede Freigaberegel lebt hier.

Die vier interagieren über die gemeinsame LOGREP-Datenbank. Eine Änderung an einem Force Module in einer Komponente erscheint bei der nächsten Synchronisation in den anderen. Die meisten Integrationsprojekte zielen direkt auf das LOGREP-Schema und behandeln ADAMS und EVE als Sichten über einem gemeinsamen Substrat.

JDLM (Joint Deployment and Logistics Model)

JDLM ist das Modellierungssystem des US Transportation Command (USTRANSCOM) für streitkräftegemeinsame Verlegung und Nachschub. Wo LOGFAS auf Koalitionsplanung zentriert ist, zentriert sich JDLM auf streitkräftegemeinsame und ressortübergreifende US-Bewegungen — und zunehmend auf die Modellierung, die erforderlich ist, um alternative Handlungsoptionen unter Beschränkungen zu bewerten.

JDLM konsumiert eine andere Upstream-Quelle: TPFDD-Einspeisungen (Time-Phased Force and Deployment Data) aus JOPES und dessen Nachfolgesystemen, JDLM-eigene Modellierungseingaben von Planern und Aufklärungs-Overlays. Seine Ausgaben sind Verlegungsoptionen, bewertet nach Zeit, Kapazität pro Verkehrsträger und Risiko. Die Interoperabilitätsgeschichte mit LOGFAS ist nicht Symmetrie — die beiden Systeme tauschen keine Datenbanken aus. Es ist Übersetzung. Ein in JDLM modellierter US-Plan muss als LOGREP-kompatible Bewegungs- und Bestandsdatensätze umformuliert werden, damit Koalitionspartner sie einlesen können.

In der Praxis bedeutet das, dass ein Übersetzungsknoten dazwischensitzt — ein kleiner Dienst, der JDLM-Exporte liest, die Feldzuordnungen anwendet, die Klassifizierungsregeln anwendet und die LOGREP-geformte Ausgabe in eine Staging-Stufe schreibt, aus der LOGFAS ziehen kann. Jeder Koalitionseinsatz, der die USA einschließt, betreibt eine Version dieses Knotens.

STANAG-2406-Familie

Die Logistik-Melde-STANAGs sitzen unter allem. STANAG 2406 deckt die Logistikmeldung im weiten Sinne ab, und die verwandten STANAGs der 2400er-Serie definieren spezifische Austauschformate — Kraftstoffmeldung, Munitionsmeldung, Verlust- und medizinische Logistikmeldung, Transportbewegungsmeldung.

Die MEDLOG-Erweiterung — medizinische Logistik — ist der Teil, den Teams am häufigsten unterschätzen. Medizinische Klasse VIII hat andere Haltbarkeitsregeln, andere Temperaturbeschränkungen, andere grenzüberschreitende Freigabeprofile und andere Meldezyklen als allgemeiner Nachschub. Eine LOGFAS-Integration, die die Klassen I bis V sauber handhabt, wird bei der Klasse VIII dennoch durch die Prüfung fallen, wenn MEDLOG nicht korrekt modelliert ist. Planen Sie es ab dem ersten Sprint ein.

Die STANAGs definieren das Wire-Format. Implementierer sollten sie als Vertrag betrachten: Alles, was die Plattform produziert, muss verlustfrei durch einen STANAG-konformen Export und zurück laufen können. Diese eine Regel fängt mehr Bugs als jede andere Disziplin.

Integrationsmuster

Drei Muster dominieren.

Pull (LOGREP abfragen). Ein externes System fragt ein LOGREP-Replikat planmäßig ab — alle fünfzehn Minuten, jede Stunde — vergleicht mit seinem letzten Snapshot und reagiert auf Änderungen. Pull ist einfach, vorhersehbar und leicht zu betreiben. Es ist auch verlustbehaftet: Wenn ein Datensatz zwischen Abfragen erstellt und gelöscht wird, sieht der Puller ihn nie. Für Planungsdaten — die im Konferenzrhythmus, nicht im Sekundenrhythmus wechseln — ist Pull korrekt.

Push (Ereignisstrom in LOGFAS). Vorgeschaltete Systeme emittieren Änderungsereignisse — ein Bestand aktualisiert, eine Bewegung ausgeführt — auf einen Nachrichtenbus, und ein LOGFAS-Adapter konsumiert sie und schreibt sie in LOGREP. Push ist näher an Echtzeit und verlustfrei, erfordert aber eine robuste Message Queue und sorgfältige Idempotenz. Für Ausführungsdaten ist Push korrekt.

Staging (Übersetzungsknoten mit Klassifizierungsschleuse). Das kanonische Koalitionsdesign. Nationale ERPs veröffentlichen an eine nationale Staging-Stufe. Ein Übersetzungsknoten — im Besitz des Integrationsteams, oft vom Upstream luftgetrennt — liest aus der Staging-Stufe, wendet Feldzuordnungen an, wendet Freigaberegeln an und schreibt in ein koalitionsseitiges LOGREP. Der Übersetzungsknoten ist der einzige Engpass, an dem Klassifizierung, Freigabefähigkeit und Schema zusammenlaufen. Bauen Sie ihn explizit. Lassen Sie ihn nicht von selbst entstehen.

Klassifizierung und Freigabefähigkeit

Nationale Logistikdaten sind standardmäßig national. NATO RESTRICTED ist die Untergrenze, auf der die meisten Koalitionsaustausche sitzen, aber derselbe Datensatz kann an die NATO freigegeben sein und nicht an eine bestimmte Partnernation, oder an eine Mission freigegeben und an eine andere nicht. Freigabefähigkeit ist nicht Klassifizierung — sie ist die orthogonale Achse, die bestimmt, wer was innerhalb einer gegebenen Klassifizierungsstufe sieht.

Das Muster, das funktioniert, heißt Sanitize-on-Egress. Jeder Datensatz trägt einen Freigabevektor — eine Menge von Nationen und Missionen, für die er genehmigt ist. Der Übersetzungsknoten weigert sich, jeden Datensatz zu schreiben, dessen Freigabevektor das Ziel nicht enthält. National sensible Felder (spezifische Chargennummern, Lieferantennamen, Endprodukt-Seriennummern) werden gestrippt oder gehasht, bevor der Datensatz die Schleuse passiert. Koalitions-Interoperabilitätsdisziplin verlangt, dass dies im Code, nicht in Richtlinien, durchgesetzt wird. Richtlinien versagen unter operativem Tempo.

Die Schleuse protokolliert auch. Jeder Datensatz, der passiert, jeder Datensatz, der abgelehnt wird, jedes Feld, das bereinigt wird — alles protokolliert mit Provenienz. Freigabe-Audits werden kommen. Seien Sie bereit.

Föderation nationaler ERPs in LOGFAS

SAP, Oracle EBS, IFS und Maximo sind die vier Upstream-Quellen, die wir am häufigsten gesehen haben. Jede bildet anders auf LOGREP ab.

SAP MM (Materials Management) trägt Bestände und Verbrauch mit hoher Genauigkeit, verwendet jedoch nationale Materialcodes — diese auf NSNs abzubilden ist die Hälfte der Integrationsarbeit. Die Abbildung ist selten eins-zu-eins; erwarten Sie eine kuratierte Cross-Walk-Tabelle, gepflegt von der Materialbehörde. Defense-ERP-Integrationsmuster gelten hier direkt.

Oracle EBS Inventory und IFS Supply haben ähnliche Formen, aber unterschiedliche Feldsemantiken — „on hand" in einem ist „available" im anderen, mit Reservierungen und in-transit inkonsistent behandelt. Lesen Sie die Felddefinitionen, nicht die Feldnamen.

Maximo, stark für Flottenwartung eingesetzt, trägt Bereitschaftsdaten bei — Fahrzeugstatus, aufgeschobene Wartung, missionsfähige Raten. Maximo speist die Bereitschaftsspalten eines LOGREP-Force-Module-Datensatzes. Fehlmodellierte Bereitschaft, und der Koalitionsplan ist auf Fiktion gebaut.

Für die Pipeline ist Change-Data-Capture (CDC) die richtige Form. Führen Sie CDC gegen das ERP aus, materialisieren Sie eine nationalseitige Projektion, transformieren Sie zur LOGREP-Form, schleusen Sie auf Freigabefähigkeit, schreiben Sie hinüber. Batch-Replikation bricht an Randfällen; die Datensatz-Disziplin von CDC fängt sie ab.

Operative Lehren

Steadfast Defender und Trident Juncture haben beide die Koalitionslogistik durchgängig in Maßstäben nahe am echten Krieg unter Druck gesetzt. Das Versagensmuster ist konsistent.

Was zuerst bricht, ist der Katalog. Der lokale Katalog einer Nation driftet von der vereinbarten NSN-Cross-Walk ab — ein neuer Artikel kommt in den Dienst, das Cross-Walk-Update wird aufgeschoben, und über Nacht produziert die LOGREP-Einspeisung „unknown materiel"-Zeilen, die nachgelagerte Konsumenten stillschweigend verwerfen. Bauen Sie Katalogdrift-Erkennung in die Pipeline ein. Alarmieren Sie noch in derselben Schicht, in der es passiert.

Was zweitens bricht, ist die Zeit. LOGREP-Zeitstempel werden in älteren Einspeisungen in Lokalzeit ohne Zone gemeldet, in neueren in UTC und in einigen operativen Kontexten in Missionszeit. Eine einzige Integration, die diese vermengt, produziert Bewegungspläne, bei denen Konvois eintreffen, bevor sie abfahren. Normalisieren Sie bei der Einspeisung auf UTC. Trauen Sie niemals einem Wanduhr-Zeitstempel.

Was drittens bricht, ist die Freigabefähigkeit. Ein Feld, das gestern freigegeben war, wird heute national sensibel — ein Lieferantenname, eine Chargennummer, ein Routendetail. Wenn Freigabefähigkeit in die Übersetzungsregeln hartkodiert ist, statt pro Datensatz mitgeführt zu werden, wird jede Änderung zu einem Code-Release. Machen Sie Freigabefähigkeit zu Daten, nicht zu Code.

Was viertens bricht, ist der Mensch in der Schleife. ADAMS-Planer und EVE-Bediener arbeiten in Schichten, und die Übergabe zwischen Schichten ist der Ort, an dem die meisten Datenqualitätsregressionen entstehen. Eine Bewegung wird von der abgehenden Schicht teilweise aktualisiert, die ankommende Schicht geht davon aus, dass der Datensatz endgültig ist, und nachgelagerte Konsumenten lesen einen halbgeschriebenen Plan ein. Die Lösung ist nicht Schulung. Die Lösung ist die Durchsetzung von Datensatz-Atomarität an der LOGREP-Grenze — partielle Schreibvorgänge werden abgelehnt, vollständige Updates erfolgreich. Drücken Sie die Beschränkung in die Schema-Schicht, wo Schichtmüdigkeit sie nicht umgehen kann.

Was über alle Übungen hinweg überlebt, ist das Team, das den Übersetzungsknoten Ende-zu-Ende besitzt — Schema, Mapping, Freigabefähigkeit, Schleuse, Audit-Log. Dieser Besitz kann nicht zwischen Nationen oder Auftragnehmern aufgeteilt werden, ohne dass die Nahtstellen zur Versagensfläche werden. Ein Team, eine Schleuse, ein verantwortlicher Eigentümer. Alles andere ist sekundär.

Die Disziplin, die überlebt, ist Datenqualität. Koalitionslogistik wird nicht durch einen klügeren Optimierer gerettet. Sie wird durch saubere Kataloge, ehrliche Bereitschaft, treue Zeitstempel und Übersetzungsschleusen gerettet, die sich weigern zu lügen. Bauen Sie dafür, und der Rest folgt. Für das breitere operative Bild decken unsere Artikel zu Verteidigungs-Lieferketten-Software und vorausschauender Wartung angrenzendes Terrain ab. Für die Fusionsarchitektur, die Logistiksignale neben ISR- und Operationsdaten konsumiert, siehe unseren Leitfaden zur Verteidigungs-Datenfusion.