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 prend toute sa valeur lorsqu’elle est implémentée dans le modèle de données, et pas seulement mentionné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, historiseurs, PLM et QMS. Lorsque cela est bien réalisé, une organisation aérospatiale multi-sites peut comparer les KPI en toute confiance, et une plateforme telle que Connect 981 peut présenter des vues standardisées des KPI de fabrication sans imposer un environnement fournisseur unique.

Cet article explique comment ISO 22400 influence la modélisation des données et l’intégration des systèmes au sein d’une infrastructure numérique aérospatiale typique. 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épendant des fournisseurs et des technologies. L’objectif est de donner aux architectes et aux ingénieurs data un plan directeur 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, ainsi qu’une plateforme d’exécution connectée aident à relier le concept à la traçabilité, à la réalité des ordres de fabrication et aux preuves prêtes pour 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 conseils 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 perdre le 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 sur l’ensemble des cycles de vie des programmes. Cela nécessite 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 dans des 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 lien qui garantit qu’un KPI tel que « disponibilité » a le même sens, quel que soit l’endroit où il est interrogé.

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

Les sites de production et de MRO aérospatiaux fonctionnent fréquemment avec une architecture 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 commandes, ainsi que plusieurs systèmes d’historisation et référentiels de données d’essais. Sans modèle sémantique partagé, chaque intégration devient un exercice de correspondance 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épondre à plusieurs questions pratiques :

• Comment faire correspondre les états d’équipement propriétaires provenant de différents fournisseurs de machines à 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 travail et aux unités de travail dans le MES et le SCADA ?
• Comment représenter les temps d’arrêt planifiés et non planifiés de façon à prendre en charge un reporting exploitable en audit dans des 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 place au-dessus des systèmes propres à chaque site de production. Connect 981 et des plateformes similaires peuvent alors consommer cette couche pour alimenter le reporting intersites des KPI aérospatiaux, tout en respectant les contraintes des systèmes locaux de chaque site.

Représenter les états d’équipement et les catégories de temps

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

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

• Tags du système de contrôle-commande (p. ex., cycle actif, alarme active, mode manuel).
• Saisie opérateur (p. ex., codes motif d’arrêt capturés au terminal MES).
• Contexte de planification (p. ex., si l’heure courante 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 seul état. C’est là qu’une table de correspondance ISO 22400 est utile : elle exprime la façon dont les signaux propres à chaque fournisseur sont associés à 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 occupé, 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 exemple, 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 exemple, 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 assurent la traçabilité : lorsqu’une revue de performance au niveau programme remet en question un KPI d’é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

Relier les ordres de fabrication 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 fabrication et les lots, qui peuvent être associés à des unités de travail et à des périodes. Pour s’aligner sur cette approche, le modèle de données doit représenter la relation entre :

• Ordres ERP (par exemple, ordres de fabrication, ordres d’atelier, 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 modèle courant utilise une entité production_operation_execution avec :

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

Cette entité constitue la passerelle entre le comportement des équipements basé sur le temps et les KPI au niveau des ordres. Elle permet de calculer de manière cohérente les 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 processus par lots, continus et discrets

Les flux de travail aérospatiaux couvrent plusieurs types de processus : assemblage discret de structures de cellule, processus 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 supposer un type de processus unique.

Les stratégies pratiques comprennent :

• L’utilisation d’un attribut commun lot_or_batch_id pour représenter les regroupements de matières ou de produits, 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/arrêt pour la matière ou le produit 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 ou du produit.
• 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 du 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 processus.

Intégrer ERP, MES, SCADA et historiens 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 façon récurrente dans les environnements numériques aérospatiaux :

• Données d’ordre et données de référence de l’ERP vers le MES, où les hiérarchies d’ordres, les gammes et les centres de charge sont synchronisés, fournissant le contexte structurel nécessaire aux KPI ISO 22400.
• Données d’événements et d’états provenant du SCADA et des contrôleurs d’équipements vers un historien 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 rebuts, les retouches et les temps liés 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 basés sur fichiers, des API REST ou des files de messages, mais l’essentiel est que chaque système fournisse des identifiants suffisants pour être relié aux objets ISO 22400 dans le modèle sémantique (identifiants d’équipement, identifiants d’ordre, identifiants de lot, horodatages et codes motif).

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

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

• Plutôt que d’envoyer des noms de tags 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’ordre et d’équipement 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 de temps 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 inter-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 un réseau de fournisseurs aérospatiaux distribué, où les sites principaux des OEM et les fournisseurs de rangs successifs doivent échanger des informations KPI de manière comparable.

Concevoir un référentiel de KPI ou un data lake aligné sur ISO 22400

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

Un référentiel de KPI ou un data lake compatible avec ISO 22400 est généralement organisé autour d’un petit ensemble de dimensions principales et de structures assimilables à des faits. Pour la fabrication aérospatiale, ces tables de dimensions comprennent 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, incluant le calendrier, les équipes et les calendriers de production avec les jours fériés et les 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 des données 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 préservent leur liberté dans le choix de leurs moteurs de stockage et de requête, tout en respectant la structure sémantique d’ISO 22400.

Gestion des métadonnées, des unités et des plages logiques

ISO 22400 met l’accent sur les métadonnées telles que les unités de mesure, les plages logiques applicables et les sens d’évolution attendus. 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 implique des structures de métadonnées explicites :

• Une table kpi_definition qui répertorie chaque KPI, sa référence ISO 22400, son unité, ses utilisateurs types (opérateur, superviseur, direction) et indique si des valeurs plus élevées sont considérées comme favorables ou défavorables.
• 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 normalisée du KPI.
• Une logique de conversion d’unités qui aligne les unités d’énergie, de débit et de temps entre les sites (par exemple, en normalisant sur les heures même si certains systèmes déclarent 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 susceptible d’être auditée ou examinée par les autorités réglementaires. Elles évitent également la redéfinition accidentelle des KPI lorsque des sites introduisent de nouveaux outils de visualisation ou rapports.

Exemples de pipelines de données compatibles avec ISO 22400

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

Considérons une cellule de fabrication composite 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 porte l’ordre de fabrication global et le planning. Un pipeline prêt pour ISO 22400 pourrait ressembler à ceci :

1. Ingérer les événements bruts depuis le SCADA (début/fin de cycle, événements d’alarme), le MES (début/fin d’opération) et le 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 mapping aux tags SCADA afin de dériver des segments RUN/STOP/IDLE/SLOW avec des heures de début et de fin fiables.
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 poste et jour.
5. Persister les agrégats et les KPI dans le référentiel de KPI, y compris la disponibilité, l’utilisation et les indicateurs liés aux ordres tels que définis par ISO 22400.

Le résultat est un pipeline auditable allant des données capteurs brutes aux KPI normalisés, adapté aux comparaisons inter-sites et, lorsque nécessaire, aux rapports de performance destinés aux clients.

Alimenter de façon cohérente les tableaux de bord et les outils d’analytique

Du côté de la consommation des données, les organisations aérospatiales peuvent utiliser une combinaison d’outils : portails internes, plateformes BI commerciales, notebooks d’analytique 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 ISO 22400, tous ces outils s’appuient sur la même source de vérité.

Les pratiques clés comprennent :

• 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 d’ISO 22400 plutôt que selon des conventions de nommage propres aux outils.
• S’assurer que les chemins d’exploration 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 les cellules d’essai moteurs ou les outillages d’assemblage structural.
• Permettre des vues propres à un 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 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

ISO 22400 n’impose pas la manière d’architecturer votre MES, votre historien ou votre data lake. Elle définit toutefois un langage partagé d’états, de catégories de temps, d’ordres et de KPI pouvant guider les décisions d’architecture. Dans les environnements aérospatiaux réglementés, où la traçabilité, la maîtrise de 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 des données systèmes hétérogènes dans un référentiel de KPI aligné sur 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 exploiter cette base 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.