Intégration JDLM et LOGFAS pour la planification du soutien de coalition

Les opérations de coalition vivent ou meurent par le soutien. Une force opérationnelle multinationale peut être brillante tactiquement et s'arrêter net parce que le carburant n'est pas arrivé au bon nœud, parce que la classe médicale VIII s'est déplacée entre deux stocks nationaux sans suivi, ou parce que le plan de transport d'une nation supposait une route que les ingénieurs d'une autre nation n'avaient pas encore réparée. Le coût d'un soutien multinational mal planifié se mesure en puissance de combat perdue — pas en erreurs de tableur.

La réponse de l'OTAN à ce problème est LOGFAS — la suite Logistics Functional Area Services — et une petite constellation d'outils de support. La réponse américaine, avec une portée interarmées et interagences plus large, est JDLM. En pratique, chaque déploiement de coalition doit intégrer les deux, plus les ERPs propres aux nations participantes. Cet article est un guide d'ingénierie de la manière dont cette intégration fonctionne réellement, ce qui se casse et ce qui tient.

Le problème du soutien de coalition

Les armées nationales ne se fédèrent pas par défaut. Chacune exécute son propre ERP — SAP chez certaines, Oracle EBS chez d'autres, IFS chez quelques-unes, des systèmes hérités sur mesure chez plus que ce qui est admis. Chacune a son propre catalogue de matériel, sa propre cartographie NSN-vers-local, son propre schéma de transport, ses propres règles de classification. Quand deux nations mettent sur pied une force opérationnelle interarmées combinée, rien de tout cela ne s'aligne automatiquement.

Le contournement historique était LOGREP — le LOGistics REPort — échangé comme un fichier plat lors des conférences de planification. LOGREP est devenu la monnaie de coalition : imparfaite, avec perte, mais convenue. Liste de Force d'une nation, état de préparation des moyens, prévision de consommation et plan de mouvement se résument tous en entrées LOGREP que d'autres partenaires de coalition peuvent lire. Aujourd'hui LOGREP est toujours la lingua franca, mais l'échange a migré du papier et de l'email vers LOGFAS et les protocoles qui l'entourent.

Le problème plus profond est que les ERPs nationaux n'ont jamais été construits pour exposer leurs internes à une coalition. Leurs données sont sensibles, leurs schémas sont commercialement confidentiels, et leurs opérateurs ne sont pas autorisés à les publier. La fédération doit être conçue — elle ne se produit pas.

Tour des composants LOGFAS

LOGFAS n'est pas une application. C'est une suite, distribuée par la NATO Communications and Information Agency (NCIA), avec quatre composants qui comptent pour tout projet d'intégration.

LOGREP est le modèle de données et la base de données. Il définit les entités — Modules de Force, Détentions, Besoins, Stocks, Besoins de Mouvement — et les relations entre eux. Tout autre composant LOGFAS lit ou écrit dans LOGREP. Quand les ingénieurs disent « intégrer avec LOGFAS », ils veulent presque toujours dire « produire ou consommer du contenu de base LOGREP ».

ADAMS (Allied Deployment and Movement System) est la surface de planification. ADAMS consomme LOGREP, applique un réseau de routes, modes et actifs de transport, et produit des plans de mouvement — qui déplace quoi, par quel mode, vers quel nœud intermédiaire, quel jour. ADAMS est l'endroit où les planificateurs de coalition passent leurs heures durant la phase de déploiement.

EVE (Effective Visible Execution) est la couche de suivi d'exécution. Là où ADAMS planifie, EVE suit les réels : où le convoi se trouve réellement, si l'avion est réellement parti, si le stock est réellement arrivé. EVE est ce qui se rapproche le plus d'une image en temps réel dans LOGFAS, bien que « temps réel » en logistique signifie souvent « positions du jour rapportées à 0700 ».

SDM (System Data Management) est l'épine dorsale administrative — utilisateurs, rôles, distribuabilité, synchronisation de base de données, gestion de catalogue. SDM est invisible aux planificateurs et central pour les intégrateurs. Chaque synchronisation inter-bases, chaque harmonisation de catalogue, chaque règle de distribuabilité vit ici.

Les quatre interopèrent à travers la base de données LOGREP partagée. Un changement à un Module de Force dans un composant apparaît dans les autres à la prochaine synchronisation. La plupart des projets d'intégration ciblent directement le schéma LOGREP, traitant ADAMS et EVE comme des vues sur un substrat partagé.

JDLM (Joint Deployment and Logistics Model)

JDLM est le système de modélisation US Transportation Command (USTRANSCOM) pour le déploiement et le soutien interarmées. Là où LOGFAS se centre sur la planification de coalition, JDLM se centre sur les mouvements interarmées et interagences américains — et de plus en plus sur la modélisation requise pour évaluer des cours d'action alternatifs sous contrainte.

JDLM consomme une source amont différente : flux TPFDD (Time-Phased Force and Deployment Data) de JOPES et ses systèmes successeurs, entrées de modélisation natives JDLM des planificateurs, et superpositions de renseignement. Ses sorties sont des options de déploiement notées selon le temps, la capacité de mode et le risque. L'histoire d'interopérabilité avec LOGFAS n'est pas la symétrie — les deux systèmes n'échangent pas de bases de données. C'est la traduction. Un plan américain modélisé dans JDLM doit être ré-exprimé comme enregistrements de mouvement et détentions compatibles LOGREP pour que les partenaires de coalition puissent l'ingérer.

En pratique cela signifie qu'un nœud de traduction siège entre les deux — un petit service qui lit les exports JDLM, applique les mappings de champs, applique les règles de classification, et écrit la sortie de forme LOGREP vers un étage que LOGFAS peut tirer. Chaque déploiement de coalition incluant les États-Unis exécute une version de ce nœud.

Famille STANAG 2406

Les STANAG de rapport logistique sont sous-jacents à tout. STANAG 2406 couvre le rapport logistique au sens large, et les STANAG associés dans la série 2400 définissent des formats d'échange spécifiques — rapport carburant, rapport munitions, rapport pertes et logistique médicale, rapport mouvement transport.

L'extension MEDLOG — logistique médicale — est la partie que les équipes sous-estiment le plus souvent. La classe médicale VIII a des règles de durée de vie différentes, des contraintes de température différentes, des profils de distribuabilité inter-nationaux différents, et des cadences de rapport différentes de l'approvisionnement général. Une intégration LOGFAS qui gère proprement les classes I à V échouera quand même à l'audit sur la classe VIII si MEDLOG n'est pas modélisé correctement. Planifiez-le dès le premier sprint.

Les STANAG définissent le format filaire. Les implémenteurs doivent les traiter comme le contrat : tout ce que la plateforme produit doit aller-retour à travers un export conforme STANAG et revenir sans perte. Cette seule règle attrape plus de bugs que toute autre discipline.

Modèles d'intégration

Trois modèles dominent.

Tirer (poll LOGREP). Un système externe interroge un réplica LOGREP selon un calendrier — toutes les quinze minutes, toutes les heures — diffère par rapport à son dernier snapshot, et agit sur les changements. Le pull est simple, prévisible et facile à opérer. Il est aussi avec perte : si un enregistrement est créé et supprimé entre deux polls, le puller ne le voit jamais. Pour les données de planification — qui changent selon la cadence des conférences, pas à la seconde — le pull est correct.

Pousser (flux d'événements dans LOGFAS). Les systèmes amont émettent des événements de changement — un stock mis à jour, un mouvement exécuté — sur un bus de messages, et un adaptateur LOGFAS les consomme et les écrit dans LOGREP. Le push est plus proche du temps réel et sans perte, mais il nécessite une file de messages robuste et une idempotence soignée. Pour les données d'exécution, le push est correct.

Staging (nœud de traduction avec porte de classification). Le design canonique de coalition. Les ERPs nationaux publient vers un étage national. Un nœud de traduction — appartenant à l'équipe d'intégration, souvent air-gappé du système amont — lit depuis l'étage, applique les mappings de champs, applique les règles de distribuabilité, et écrit vers un LOGREP côté coalition. Le nœud de traduction est l'unique point d'étranglement où classification, distribuabilité et schéma convergent tous. Construisez-le explicitement. Ne le laissez pas émerger.

Classification et distribuabilité

Les données logistiques nationales sont, par défaut, nationales. NATO RESTRICTED est le plancher sur lequel siègent la plupart des échanges de coalition, mais le même enregistrement peut être distribuable à l'OTAN et non à une nation partenaire spécifique, ou distribuable à une mission et non à une autre. La distribuabilité n'est pas la classification — c'est l'axe orthogonal qui détermine qui voit quoi dans un niveau de classification donné.

Le modèle qui fonctionne est l'assainissement en sortie. Chaque enregistrement porte un vecteur de distribuabilité — un ensemble de nations et de missions pour lesquelles il est approuvé. Le nœud de traduction refuse d'écrire tout enregistrement dont le vecteur de distribuabilité n'inclut pas la destination. Les champs qui sont nationalement sensibles (numéros de lots spécifiques, noms de fournisseurs, numéros de série d'articles finaux) sont strippés ou hashés avant que l'enregistrement ne traverse la porte. La discipline d'interopérabilité de coalition exige que ceci soit appliqué dans le code, pas dans la politique. La politique échoue sous le tempo opérationnel.

La porte journalise aussi. Chaque enregistrement qui traverse, chaque enregistrement rejeté, chaque champ assaini — journalisé avec provenance. Les audits de distribuabilité viendront. Soyez prêts.

Fédérer les ERPs nationaux dans LOGFAS

SAP, Oracle EBS, IFS et Maximo sont les quatre sources amont que nous avons vues le plus souvent. Chacune se mappe à LOGREP différemment.

SAP MM (Materials Management) porte les détentions et la consommation avec une haute fidélité mais utilise des codes de matériel nationaux — mapper ceux-ci aux NSN est la moitié du travail d'intégration. Le mapping est rarement un-pour-un ; attendez-vous à une table de correspondance curée maintenue par l'autorité de matériel. Les modèles d'intégration ERP défense s'appliquent directement ici.

Oracle EBS Inventory et IFS Supply ont des formes similaires mais des sémantiques de champs différentes — « en stock » chez l'un est « disponible » chez l'autre, avec les réservations et le en-transit gérés de manière incohérente. Lisez les définitions de champs, pas les noms de champs.

Maximo, utilisé fortement pour la maintenance de flotte, contribue les données de préparation — état des véhicules, maintenance différée, taux de capacité de mission. Maximo alimente les colonnes de préparation d'un enregistrement Module de Force LOGREP. Mal modélisez la préparation et le plan de coalition est construit sur de la fiction.

Pour le pipeline, change-data-capture (CDC) est la bonne forme. Exécutez CDC contre l'ERP, matérialisez une projection côté national, transformez en forme LOGREP, ouvrez la porte sur la distribuabilité, écrivez de l'autre côté. La réplication par lots se casse sur les cas limites ; la discipline par enregistrement de CDC les attrape.

Leçons opérationnelles

Les exercices Steadfast Defender et Trident Juncture ont tous deux testé la logistique de coalition de bout en bout à des échelles proches de la guerre réelle. Le schéma de défaillance est cohérent.

Ce qui se casse en premier est le catalogue. Le catalogue local d'une nation dérive du cross-walk NSN convenu — un nouvel article entre en service, la mise à jour du cross-walk est reportée, et du jour au lendemain le flux LOGREP produit des lignes « matériel inconnu » que les consommateurs en aval laissent tomber silencieusement. Construisez la détection de dérive du catalogue dans le pipeline. Alertez dessus le même quart où cela se produit.

Ce qui se casse en second est le temps. Les horodatages LOGREP sont rapportés en heure locale sans zone dans les flux plus anciens, en UTC dans les plus récents, et en heure de mission dans certains contextes opérationnels. Une seule intégration qui confond ceci produit des plans de mouvement où les convois arrivent avant de partir. Normalisez en UTC à l'ingestion. Ne faites jamais confiance à un horodatage murale.

Ce qui se casse en troisième est la distribuabilité. Un champ qui était distribuable hier devient nationalement sensible aujourd'hui — un nom de fournisseur, un numéro de lot, un détail de route. Si la distribuabilité est codée en dur dans les règles de traduction plutôt que portée par enregistrement, chaque changement devient une release de code. Faites de la distribuabilité une donnée, pas du code.

Ce qui se casse en quatrième est l'humain dans la boucle. Les planificateurs ADAMS et les opérateurs EVE travaillent par rotation de quarts, et la passation entre quarts est l'endroit où la plupart des régressions de qualité de données entrent. Un mouvement est partiellement mis à jour par le quart sortant, le quart entrant suppose que l'enregistrement est final, et les consommateurs en aval ingèrent un plan à moitié écrit. La solution n'est pas la formation. La solution est d'imposer l'atomicité au niveau de l'enregistrement à la frontière LOGREP — les écritures partielles sont rejetées, les mises à jour complètes réussissent. Poussez la contrainte dans la couche schéma où la fatigue de quart ne peut pas la contourner.

Ce qui survit à travers les exercices est l'équipe qui possède le nœud de traduction de bout en bout — schéma, mapping, distribuabilité, porte, journal d'audit. Cette propriété ne peut pas être divisée entre nations ou contractants sans que les coutures ne deviennent la surface de défaillance. Une équipe, une porte, un propriétaire responsable. Tout le reste est secondaire.

La discipline qui survit est la qualité des données. La logistique de coalition ne sera pas sauvée par un optimisateur plus intelligent. Elle sera sauvée par des catalogues propres, une préparation honnête, des horodatages fidèles, et des portes de traduction qui refusent de mentir. Construisez pour cela et le reste suit. Pour l'image opérationnelle plus large, nos articles sur le logiciel de chaîne d'approvisionnement défense et la maintenance prédictive couvrent le terrain adjacent. Pour l'architecture de fusion qui consomme les signaux logistiques aux côtés des données ISR et opérationnelles, voir notre guide de fusion de données défense.