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 le plus puissant lorsqu’il est implémenté dans le modèle de données, et pas seulement cité 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 opération aérospatiale multisite 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 une pile 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 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 ISO 22400.

Pour les équipes qui mettent ce sujet en œuvre 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, du guide des opérations aérospatiales de Connect 981 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 exige un modèle de données bien pensé

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 n’impose 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 issus des équipements, des bancs d’essai et des postes d’assemblage (par ex., tags PLC, événements de programmes NC, début/fin d’inspection manuelle).
• États dérivés et segments de temps, où chaque période continue 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 segments de temps et quantités dans des concepts définis par ISO 22400, tels que la disponibilité ou le taux d’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é » conserve la même signification quel que soit l’endroit où il est interrogé.

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

Les installations de production aéronautique et de MRO fonctionnent fréquemment avec une pile 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 historians et référentiels de données d’essai. Sans modèle sémantique partagé, chaque intégration devient un exercice de mapping spécifique, 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 de différents constructeurs 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 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 d’une manière qui permette un reporting adapté aux audits dans des environnements AS9100 ?

La réponse est 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

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

L’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érivés d’une combinaison de :

• Variables du système de contrôle-commande (p. ex., cycle actif, alarme active, mode manuel).
• Saisie opérateur (p. ex., codes de motif d’arrêt saisis 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 comportant 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 à l’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. Un pipeline de normalisation doit les consolider en segments temporels propres, non chevauchants, associés à un état unique. C’est là qu’une table de correspondance ISO 22400 est précieuse : elle exprime comment les signaux propres à un fournisseur sont mappés vers 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 — construites à partir de ces segments d’état.

Pour les usines aérospatiales, une structure equipment_time_summary quotidienne ou par équipe est utile. Elle peut inclure :

• equipment_id et time_bucket (par exemple, jour, équipe ou période personnalisée).
• Durées par état normalisé (RUN, STOP, IDLE, SLOW).
• Durées par catégorie d’arrêt (planifié ou non planifié, lié à la sécurité, lié à la qualité, maintenance).
• Indicateurs de 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 apportent de 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

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 uniquement par équipement. La norme 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. 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 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, postes, 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 unités.
• Lien configuration_id ou effectivity pour les pièces sous gestion de configuration.

Cette entité constitue le lien entre le comportement des équipements dans le temps et les KPI au niveau des ordres. Elle permet de calculer de manière cohérente des concepts ISO 22400 tels que la structure des 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 exploitation quasi continue dans les installations d’essais. 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 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, qu’il s’agisse de lots de coulée, de kits de drapage composite ou de modules moteurs.
• La capture des événements de démarrage/arrêt pour 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 possibilité d’opérations chevauchantes sur le même ordre de fabrication (p. ex., cycles d’essais 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 procédés.

Intégration ERP, MES, SCADA et systèmes d’historisation

Modèles d’intégration et interfaces courants

ISO 22400 ne prescrit aucun protocole de transport ni format de message, mais certains modèles d’intégration apparaissent de manière 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 pour les KPI ISO 22400.
• Données d’événements et d’états issues du SCADA et des contrôleurs d’équipements vers un système d’historisation 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 le rebut, la reprise 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 par fichiers, des API REST ou des files de messages, mais l’essentiel est que chaque système fournisse des identifiants suffisants pour être associés aux objets ISO 22400 dans le modèle sémantique (ID d’équipement, ID d’ordre, ID de lot, horodatages et codes 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 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 cohérents d’ordre et d’équipement, alignés sur le 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 temps d’arrêt et aux KPI de performance.

Des plateformes comme Connect 981 peuvent ensuite 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 une base d’approvisionnement aérospatiale distribuée, où les sites principaux des OEM et les fournisseurs de rangs successifs doivent échanger des informations KPI de manière comparable.

Concevoir un magasin de KPI ou un lac de données aligné sur ISO 22400

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

Un référentiel de KPI ou un data lake tenant compte d’ISO 22400 est généralement organisé autour d’un petit ensemble de dimensions principales et de structures de type 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 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 préservent leur liberté de choix en matière de 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 directions d’évolution 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 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 typiques (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 enregistrent 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 de production 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 susceptible d’être soumise à un audit ou à un examen 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 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 porte l’ordre de production global et le planning. Une chaîne de traitement prête pour ISO 22400 pourrait se présenter comme suit :

1. Ingérer les événements bruts depuis le SCADA (début/fin de cycle, événements d’alarme), le MES (début/achèvement d’opération) et le QMS (création de non-conformité) dans un hub central d’événements 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 horodatages de début et de fin fiabilisés.
3. Enrichir les événements avec le contexte d’ordre et de configuration par rapprochement avec les données ERP et PLM, en s’assurant 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. Enregistrer durablement les agrégats et les KPI dans le référentiel KPI, notamment la disponibilité, le taux d’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 brutes des capteurs jusqu’aux KPI normalisés, adaptée aux comparaisons inter-sites et aux rapports de performance destinés aux clients lorsque cela est nécessaire.

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

Côté consommation des données, les organisations aérospatiales peuvent utiliser une combinaison d’outils : portails internes, plateformes BI commerciales, notebooks d’analyse d’ingénierie et tableaux de bord spécialisés pour les revues de programme. En exposant les KPI via une couche sémantique commune alignée sur ISO 2240, 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 à un outil.
• Veiller à préserver les parcours d’exploration détaillée depuis le KPI jusqu’aux événements sous-jacents, 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’essais moteurs ou les outillages d’assemblage structural.
• Permettre des découpages propres à chaque 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 de données ou votre lac de données. Elle définit toutefois un langage partagé des états, des catégories de temps, des ordres et des KPI, qui peut guider 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 essentielles, 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 hétérogènes des systèmes 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 ce socle pour soutenir les initiatives de fil numérique, la visibilité fournisseurs et les cadres de KPI alignés sur les standards, 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.