Construire des modèles de données alignés sur ISO 22400 pour la fabrication connectée

Pour les fabricants de l’aérospatiale et de la défense, ISO 22400 est d’autant plus utile lorsqu’elle est mise en œuvre dans le modèle de données, et pas seulement citée dans une spécification. La norme définit la manière dont les KPI de fabrication doivent être structurés sur le plan conceptuel, mais les équipes d’ingénierie doivent encore décider comment représenter ces concepts dans les bases de données, les flux d’événements et les intégrations entre ERP, MES, SCADA, systèmes d’historisation, PLM et QMS. Lorsque cela est bien réalisé, une organisation aérospatiale multi-sites peut comparer ses KPI en toute confiance, et une plateforme telle que Connect 981 peut présenter des vues standardisées des KPI de fabrication sans imposer une pile technologique d’un fournisseur unique.

Cet article explique comment ISO 22400 influence la modélisation des données et l’intégration des systèmes dans une infrastructure numérique aérospatiale type. Il se concentre sur la représentation des états des équipements, des ordres et des catégories de temps dans une couche KPI cohérente, tout en restant indépendante des fournisseurs et des technologies. L’objectif est de fournir aux architectes et aux ingénieurs data un cadre clair pour aligner des systèmes hétérogènes sur la sémantique d’ISO 22400.

Pour les équipes qui mettent ce sujet en pratique au quotidien, la gouvernance des KPI ISO 22400, les parcours d’intégration ERP, MES et PLM et une plateforme d’exécution connectée aident à relier le concept à la traçabilité, à la réalité des ordres de fabrication et à des preuves prêtes pour l’audit.

Le même modèle opérationnel dépend également des solutions d’exécution aérospatiale de Connect 981, d’exemples réels d’exécution aérospatiale, des recommandations de Connect 981 pour les opérations aérospatiales et des FAQ pratiques sur les opérations aérospatiales, en particulier lorsque les décisions doivent circuler entre qualité, production, fournisseurs et direction de programme sans perte de contexte.

Pourquoi ISO 22400 nécessite un modèle de données réfléchi

Des définitions conceptuelles aux structures de base de données

ISO 22400 est volontairement conceptuelle. Elle définit des KPI, des catégories de temps et des objets tels que les unités de travail et les ordres de production, mais elle ne prescrit pas la manière dont ces éléments doivent être stockés dans des tables, des topics ou des data lakes. Dans un environnement aérospatial, toutefois, les KPI doivent être auditables, traçables jusqu’aux événements sous-jacents et reproductibles tout au long des cycles de vie des programmes. Cela exige des décisions explicites de modélisation des données.

Au minimum, un modèle tenant compte d’ISO 22400 doit capturer trois couches :

• Signaux et événements bruts provenant des équipements, des bancs d’essai et des postes d’assemblage (par exemple, tags PLC, événements de programme CN, début/fin d’inspection manuelle).
• États dérivés et segments temporels, où chaque période contiguë est étiquetée avec un état pertinent au regard d’ISO 22400, tel que RUN, STOP, IDLE ou SLOW.
• Indicateurs agrégés et KPI qui combinent des segments temporels et des quantités en concepts définis par ISO 22400, tels que la disponibilité ou l’utilisation des équipements.

Ces couches peuvent résider dans différents systèmes : SCADA pour les signaux, MES pour les événements de haut niveau, un historien pour les données de séries temporelles denses, et une plateforme de données cloud pour l’agrégation. Le modèle de données est le liant qui garantit qu’un KPI tel que « disponibilité » a la même signification quel que soit l’endroit où il est interrogé.

Garantir la cohérence entre des systèmes hétérogènes

Les sites de production aéronautique et de MRO exploitent fréquemment une pile applicative hétérogène : un MES historique dans l’atelier, un système PLM moderne définissant les configurations, un ERP gérant les ordres, ainsi que plusieurs historisateurs et référentiels de données d’essai. Sans modèle sémantique partagé, chaque intégration devient un exercice de mapping sur mesure, et les définitions des KPI dérivent au fil du temps.

ISO 22400 fournit un vocabulaire de référence, mais la mise en œuvre doit résoudre plusieurs questions pratiques :

• Comment mapper les états d’équipement propriétaires provenant de différents fournisseurs de machines vers un modèle commun RUN/STOP/IDLE/SLOW ?
• Comment relier de manière cohérente les ordres de production de l’ERP aux centres de charge et aux unités de travail dans le MES et le SCADA ?
• Comment représenter les arrêts planifiés par rapport aux arrêts non planifiés d’une manière qui prenne en charge un reporting compatible avec les audits dans les environnements AS9100 ?

La réponse consiste en un modèle de données partagé, aligné sur ISO 22400 — souvent mis en œuvre sous forme de couche sémantique ou de référentiel de KPI — qui se situe au-dessus des systèmes propres à chaque site. Connect 981 et des plateformes similaires peuvent alors consommer cette couche pour alimenter le reporting des KPI aéronautiques multi-sites, tout en respectant les contraintes des systèmes locaux de chaque site.

Représenter les états des équipements et les catégories de temps

Enregistrer RUN, STOP, IDLE, SLOW dans les données d’événements

ISO 22400 considère les états des équipements comme le socle de nombreux KPI liés aux équipements. Pour les centres d’usinage aérospatiaux, les autoclaves, les machines de drapage composite, les cellules d’essais et les postes d’assemblage, ces états sont généralement dérivés d’une combinaison de :

• Tags du système de commande (p. ex., cycle actif, alarme active, mode manuel).
• Saisie opérateur (p. ex., codes de motif d’arrêt enregistrés au terminal MES).
• Contexte de planification (p. ex., si l’heure actuelle se situe dans le temps de production planifié pour cette ressource).

Un modèle d’événements robuste représente explicitement les transitions d’état. Un schéma courant est une structure equipment_state_event avec des champs tels que :

• equipment_id (identifiant de l’unité de travail, aligné sur les niveaux IEC 62264).
• state_code (normalisé en RUN, STOP, IDLE, SLOW ou autres états liés à ISO 22400).
• reason_code (détail propre au site, p. ex., TOOL_CHANGE, PROGRAM_LOAD, QUALITY_HOLD).
• start_time et end_time (ou heure de début plus durée).
• source_system (SCADA, MES, saisie manuelle, etc.).

Les événements bruts issus des machines ou du SCADA peuvent être bruités, avec des transitions rapides et des conditions transitoires. Une chaîne de normalisation doit les consolider en segments temporels propres, sans chevauchement, associés à un état unique. C’est ici qu’une table de correspondance ISO 22400 est utile : elle exprime comment les signaux propres aux fournisseurs correspondent à un state_code standard.

Agréger les données d’état dans des structures adaptées aux indicateurs

Une fois les états modélisés sous forme de segments temporels, l’agrégation orientée KPI devient directe. ISO 22400 s’appuie fortement sur des catégories de temps — telles que le temps de fonctionnement, le temps d’occupation, les arrêts planifiés et les arrêts non planifiés — qui sont construites à partir de ces segments d’état.

Pour les usines aérospatiales, une structure equipment_time_summary quotidienne ou au niveau de l’équipe est utile. Elle peut inclure :

• equipment_id et time_bucket (par ex., jour, équipe ou période personnalisée).
• Les durées par état normalisé (RUN, STOP, IDLE, SLOW).
• Les durées par catégorie d’arrêt (planifié vs non planifié, lié à la sécurité, lié à la qualité, maintenance).
• Des indicateurs pour les conditions particulières (par ex., introduction d’un nouveau programme, périodes d’inspection du premier article (FAI)).

Ces synthèses remplissent deux objectifs. Premièrement, elles prennent en charge des KPI alignés sur ISO 22400, tels que l’utilisation et la disponibilité. Deuxièmement, elles fournissent une traçabilité : lorsqu’une revue de performance au niveau programme met en question un KPI équipement, les ingénieurs peuvent remonter depuis un KPI vers une synthèse temporelle, puis vers les événements d’état sous-jacents et les signaux SCADA.

Modéliser les ordres, les lots et les événements de production

Associer les ordres de production aux équipements et au temps

Dans la fabrication aérospatiale, la performance est souvent évaluée par programme, configuration ou actif sérialisé, plutôt que seulement par équipement. ISO 22400 traite ce point en définissant des objets tels que les ordres de production et les lots, qui peuvent être associés à des unités de travail et à des périodes de temps. Pour s’aligner sur cette approche, le modèle de données doit représenter la relation entre :

• Ordres ERP (par exemple, ordres de production, ordres de fabrication, ordres de réparation).
• Opérations MES (étapes de gamme, instructions de travail, programmes CN).
• Unités de travail et centres de charge (machines, cellules, baies, bancs d’essai).

Un schéma courant utilise une entité production_operation_execution avec :

• order_id et operation_id (provenant de l’ERP/MES).
• equipment_id et, le cas échéant, work_center_id.
• start_time, end_time et scheduled_time.
• good_quantity, rework_quantity, scrap_quantity, avec les unités.
• configuration_id ou lien effectivity pour les pièces soumises à maîtrise de configuration.

Cette entité établit le lien entre le comportement des équipements fondé sur le temps et les KPI au niveau de l’ordre. Elle permet de calculer de manière cohérente des concepts ISO 22400 tels que la structure du temps de production et la fiabilité d’exécution des ordres, même lorsque les ordres sous-jacents proviennent de plusieurs instances ERP ou d’outils de planification hérités.

Gérer les procédés par lots, continus et discrets

Les flux de travail aérospatiaux couvrent plusieurs types de procédés : assemblage discret de structures de cellule, procédés par lots dans les procédés spéciaux et les revêtements, et fonctionnement quasi continu dans les installations d’essai. ISO 22400 est conçue pour couvrir les industries par lots, continues et discrètes ; le modèle de données doit donc éviter de présupposer un type de procédé unique.

Les stratégies pratiques comprennent :

• L’utilisation d’un attribut commun lot_or_batch_id pour représenter les regroupements de matière ou de produit, qu’il s’agisse de lots de coulée, de kits de drapage composite ou de modules moteur.
• La capture des événements de début/fin relatifs à la matière indépendamment des événements d’état des équipements, afin que les KPI puissent distinguer la disponibilité des équipements de la disponibilité de la matière.
• La prise en charge d’opérations qui se chevauchent sur le même ordre de fabrication (par exemple, cycles d’essai parallèles, plusieurs postes travaillant sur différentes sections d’un même fuselage).

Cette flexibilité garantit que les KPI ISO 22400 conservent leur signification sur toute l’étendue des opérations aérospatiales — de l’usinage de précision aux essais environnementaux — sans nécessiter de définitions distinctes par famille de procédés.

Intégrer ERP, MES, SCADA et historians de données

Schémas d’intégration et interfaces courants

ISO 22400 ne prescrit aucun protocole de transport ni format de message, mais certains schémas d’intégration apparaissent de manière récurrente dans les environnements numériques aérospatiaux :

• Données d’ordres et données de référence de l’ERP vers le MES, où les hiérarchies d’ordres, les gammes et les postes de charge sont synchronisés, fournissant le contexte structurel pour les KPI ISO 22400.
• Données d’événements et d’états provenant du SCADA et des contrôleurs d’équipement vers un historian de données ou un hub d’événements, qui sont ensuite normalisées en états de type ISO 22400 pour le calcul des KPI.
• Résultats qualité provenant du QMS et des systèmes d’inspection alimentant la même couche sémantique afin que les temps liés au rebut, à la reprise et aux non-conformités soient catégorisés de manière cohérente.

Les interfaces peuvent être mises en œuvre via OPC UA, des transferts par fichiers, des API REST ou des files de messages, mais l’essentiel est que chaque système fournisse des identifiants suffisants pour être rattaché aux objets ISO 22400 dans le modèle sémantique (ID d’équipement, ID d’ordre, ID de lot, horodatages et codes de motif).

Utiliser ISO 22400 comme couche sémantique pour l’échange de données

Au lieu de connecter directement chaque système à tous les autres, de nombreuses organisations aérospatiales adoptent une couche sémantique qui sert d’intermédiaire pour les intégrations. Les concepts d’ISO 22400 deviennent le vocabulaire de cette couche. Par exemple :

• Plutôt que d’envoyer des noms de balises bruts, le SCADA publie des messages equipment_state_event normalisés avec des codes d’état de type ISO 22400.
• Le MES publie des événements operation_execution en utilisant des identifiants d’ordres et d’équipements cohérents, conformes au modèle sémantique.
• Le QMS publie des messages quality_event qui font référence aux mêmes opérations et lots, ce qui permet de rattacher le temps lié aux rebuts aux KPI d’arrêt et de performance.

Des plateformes comme Connect 981 peuvent alors s’abonner à ces flux normalisés et fournir des tableaux de bord KPI et des analyses multi-sites sans avoir à interpréter à chaque fois des codes propres à chaque usine. Cette approche est particulièrement utile lorsqu’il s’agit de travailler avec une base fournisseurs aérospatiale distribuée, où les sites OEM principaux et les fournisseurs de rangs successifs doivent échanger des informations KPI de manière comparable.

Concevoir un référentiel de KPI ou un lac de données aligné sur ISO 22400

Considérations de schéma pour les requêtes KPI

Un magasin de KPI ou un data lake tenant compte de l’ISO 22400 est généralement organisé autour d’un petit ensemble de dimensions centrales et de structures de type faits. Pour la fabrication aérospatiale, ces tables de dimensions incluent souvent :

• Équipements et unités de travail, y compris les correspondances avec les actifs physiques, les emplacements et les centres de responsabilité.
• Ordres et opérations, alignés avec l’ERP et le MES, avec des attributs tels que le programme, la plateforme et le contrat client.
• Temps, y compris le calendrier, les équipes et les calendriers de production avec jours fériés et arrêts planifiés.
• Matières et configurations, reliant les KPI aux références article, aux révisions et aux référentiels de configuration.

Les structures de faits contiennent ensuite des données normalisées au niveau événementiel et agrégées :

• fact_equipment_state pour les segments d’état.
• fact_operation_execution pour les événements de production liés aux ordres.
• fact_quality_outcome pour les résultats d’inspection et d’essai.
• fact_kpi_snapshot pour les valeurs de KPI ISO 22400 précalculées par période et par niveau (équipement, ligne, usine, programme).

En conservant un schéma indépendant de la technologie (schéma en étoile, tables larges ou jeux de données Parquet de type lakehouse), les organisations gardent leur liberté de choix en matière de moteurs de stockage et de requête tout en respectant la structure sémantique de l’ISO 22400.

Gérer les métadonnées, les unités et les plages logiques

L’ISO 22400 met l’accent sur les métadonnées telles que les unités de mesure, les plages logiques applicables et les orientations de tendance attendues. Les programmes aérospatiaux exigent souvent ces informations pour la documentation, les standards internes et le reporting client. Dans le référentiel de KPI, cela suggère des structures de métadonnées explicites :

• Une table kpi_definition qui liste chaque KPI, sa référence ISO 22400, son unité, les utilisateurs types (opérateur, superviseur, direction) et indique si des valeurs plus élevées sont considérées comme bonnes ou mauvaises.
• Des tables facultatives kpi_threshold ou kpi_target qui capturent les objectifs propres à un site ou à un programme sans les confondre avec la définition standardisée du KPI.
• Une logique de conversion des unités qui aligne les unités d’énergie, de débit et de temps entre les sites (par exemple, en standardisant sur les heures, même si certains systèmes remontent des minutes ou des secondes).

Ces métadonnées facilitent la création de tableaux de bord, de contrôles automatisés et d’alertes dans les environnements aérospatiaux où l’interprétation des KPI doit être cohérente entre les programmes et soumise à audit ou à revue réglementaire. Elles évitent également la redéfinition accidentelle des KPI lorsque les sites introduisent de nouveaux outils de visualisation ou de nouveaux rapports.

Exemples de pipelines de données prêts pour l’ISO 22400

Flux d’ingestion et de transformation des événements

Considérez une cellule de fabrication de composites produisant des structures de vol critiques. Les systèmes SCADA capturent les données de cycle d’autoclave et les états des postes de drapage ; le MES gère les instructions de travail et le statut des ordres ; l’ERP détient l’ordre de production global et le planning. Une chaîne de traitement compatible ISO 22400 pourrait ressembler à ceci :

1. Ingérer les événements bruts provenant du SCADA (début/fin de cycle, événements d’alarme), du MES (début/achèvement d’opération) et du QMS (création de non-conformité) dans un hub d’événements central ou une plateforme de streaming.
2. Normaliser les états des équipements en appliquant des règles de correspondance aux tags SCADA afin de dériver des segments RUN/STOP/IDLE/SLOW avec des heures de début et de fin propres.
3. Enrichir les événements avec le contexte d’ordre et de configuration en les rapprochant des données ERP et PLM, afin de garantir que chaque événement est associé au bon ordre, à la bonne configuration et au bon programme.
4. Calculer les catégories de temps et les indicateurs, tels que le temps de fonctionnement, les arrêts planifiés et les arrêts non planifiés, aux niveaux du poste et de la journée.
5. Persister les agrégats et les KPI dans le référentiel de KPI, notamment la disponibilité, l’utilisation et les indicateurs liés aux ordres tels que définis par ISO 22400.

Le résultat est une chaîne de traitement auditable, depuis les données capteurs brutes jusqu’aux KPI standardisés, adaptée aux comparaisons entre sites et, lorsque nécessaire, aux rapports de performance destinés aux clients.

Alimenter de manière cohérente les tableaux de bord et les outils d’analytics

Côté consommation des données, les organisations aérospatiales peuvent utiliser une combinaison d’outils : portails internes, plateformes de BI commerciales, notebooks d’analytics d’ingénierie et tableaux de bord spécialisés pour les revues de programme. En exposant les KPI au travers d’une couche sémantique commune alignée sur l’ISO 2240, tous ces outils s’appuient sur la même source de vérité.

Les pratiques clés incluent :

• Fournir une API stable et documentée ou une interface SQL pour l’accès aux KPI, avec des KPI décrits selon les concepts de l’ISO 22400 plutôt qu’au moyen de conventions de nommage propres à un outil.
• S’assurer que les chemins d’analyse détaillée depuis le KPI jusqu’aux événements sous-jacents sont préservés, afin de soutenir l’analyse des causes racines des problèmes de disponibilité ou de performance sur des actifs à forte valeur, tels que des bancs d’essai moteur ou des outillages d’assemblage structurel.
• Permettre des vues par programme (par exemple par plateforme ou par client) sans redéfinir les KPI eux-mêmes, mais uniquement les filtres appliqués.

Dans ce modèle, Connect 981 ou une plateforme de fabrication numérique similaire peut coordonner le reporting des KPI à l’échelle de l’entreprise aérospatiale, tandis que le modèle de données aligné sur l’ISO 22400 garantit que chaque usine, fournisseur et programme interprète ces KPI de la même manière.

Mettre en pratique la modélisation des données ISO 22400 dans l’aérospatial

L’ISO 22400 ne prescrit pas l’architecture de votre MES, de votre historien de données ou de votre lac de données. Elle définit toutefois un langage commun des états, des catégories de temps, des ordres et des KPI, qui peut orienter les décisions d’architecture. Dans les environnements aérospatiaux réglementés, où la traçabilité, la maîtrise de la configuration et la comparabilité entre sites sont importantes, la mise en œuvre de ce langage dans le modèle de données apporte des bénéfices tangibles.

En représentant les états des équipements sous forme d’événements normalisés, en reliant les ordres et les opérations entre ERP et MES, et en consolidant les données de systèmes hétérogènes dans un référentiel de KPI aligné sur l’ISO 22400, les fabricants aérospatiaux peuvent obtenir un reporting de performance cohérent et prêt pour l’audit. Des plateformes comme Connect 981 peuvent ensuite s’appuyer sur cette fondation pour soutenir les initiatives de fil numérique, la visibilité fournisseurs et les cadres de KPI alignés sur les normes, sans imposer une pile technologique unique. La norme fournit la sémantique ; le modèle de données transforme cette sémantique en réalité opérationnelle.