Nous avons conçu un modèle IT/OT reproductible pour cinq domaines OT, des outils de salle blanche aux entrepôts.
Nous avons construit un Unified Namespace qui donne à plus de 15 000 équipements de support une seule adresse et une seule signification.
Nous avons fait circuler des données modélisées et contextualisées du terrain jusqu'à la plateforme de données cloud d'imec.
imec exploite certaines des salles blanches les plus avancées d'Europe. Plus de 250 outils de salle blanche s'appuient sur plus de 15 000 équipements pour les procédés, le HVAC, les gaz, l'énergie et les systèmes de sécurité. Ces équipements sont répartis sur cinq domaines OT très différents : les fabs (FAB), les installations (FAIN), les laboratoires (LAB), les bureaux et les entrepôts. Chaque domaine a ses propres fournisseurs, protocoles et générations d'équipements, des outils semi-conducteurs aux interfaces standard et propriétaires jusqu'aux systèmes DCS et automates classiques et aux systèmes de bâtiment de type IT.
Au fil des ans, les données se sont retrouvées enfermées dans ces systèmes. Chaque nouveau cas d'usage arrivait avec sa propre pile et sa propre intégration point à point, et chaque intégration était un projet en soi. Une vue transversale, par exemple de la consommation d'énergie entre la fab et les installations, était difficile à obtenir.
Avec de nouvelles salles blanches en préparation, FAB4 à Louvain et une nouvelle fab à Málaga, imec a vu le moment de bien faire les choses dès le départ. L'objectif : rendre les données énergétiques accessibles à chaque responsable d'outil et d'installation, et pas à un seul spécialiste, préparer les données opérationnelles pour l'IA, et ne plus payer pour des intégrations point à point à l'échelle de 15 000 équipements.
En collaboration avec imec, nous avons conçu une architecture cible répétée par domaine : une passerelle edge et un broker par domaine, un historian partagé, et un broker d'entreprise dans la DMZ qui alimente la plateforme de données cloud d'imec. Un Unified Namespace donne à chaque donnée une seule adresse et une seule signification, du site jusqu'au tag.
Les domaines publient une seule fois, et chaque consommateur s'abonne. Les équipes opérationnelles lisent les données en direct dans l'historian partagé en quelques secondes, tandis que le même flux modélisé alimente Azure, Databricks et Power BI pour l'analyse et l'IA. Les nouveaux outils, les utilités et même les nouvelles fabs s'intègrent au même modèle dès le premier jour. Ajouter un domaine ou une fab revient désormais à répéter le modèle, pas à concevoir une nouvelle intégration.
Propulsé par
imec et Coretecs, c'est une longue histoire : nous travaillons côte à côte depuis notre tout premier jour, et les installations d'imec fonctionnent déjà avec la bibliothèque d'automatisation que nous avons co-créée. Pour ce projet, notre périmètre allait du capteur jusqu'à Kafka : tout le côté OT, jusqu'au point où des données modélisées et contextualisées entrent dans la plateforme de données cloud d'imec.
Le parcours a duré environ deux ans. L'architecture a été conçue et le premier domaine mis en service en 2024. En 2025, l'historian est devenu un service partagé, le flux Kafka vers Azure a été mis en service, et Databricks et Power BI ont été connectés.
Connecter la première machine n'est jamais le problème. Le répéter sur cent systèmes, cinq domaines ou plusieurs sites, si. Le même signal porte facilement cinq noms différents : FT_201.PV dans un système, Flow_lmin ou DB40.DBD12 dans le suivant.
C'est pourquoi nous concevons model-firstNous partons des besoins de l'entreprise, nous définissons les modalités de calcul, puis le modèle d'information que chaque équipement doit fournir. Ce n'est qu'ensuite que nous examinons la provenance actuelle des données.
Prenons une question telle que « Quel outil consomme le plus d'énergie par heure de production, par équipe ? »La logique repose sur la somme de la puissance active dans le temps, répartie selon l'état de l'outil. Le modèle impose donc que chaque outil fournisse un tool_id, un active_power_kW, un tool_state et un shift_id. L'état provient de l'outil de fabrication via SECS/GEM, la puissance d'un compteur des installations via Modbus, et le planning des équipes du MES. Trois fournisseurs peuvent nommer ce signal de puissance PWR.ACT_KW, DB12.DBD40 ou Meter7/kW : il est mappé une seule fois, à la source, sur le même attribut du modèle. (Exemple illustratif.)
Ceux qui connaissent la signification d'un signal travaillent sur le terrain. En ajoutant le contexte à cet endroit, une seule fois, il accompagne la donnée jusqu'à chaque utilisateur.
Chaque domaine reçoit les mêmes briques :
Sur site, les brokers et les passerelles tournent sur Red Hat OpenShift. Les brokers sont des HiveMQet la couche edge combine le meilleur outil par domaine, notamment Ignition, Litmus et Siemens.
Le Unified Namespace offre à imec une vision unique, structurée et en temps réel du campus via MQTT. Chaque donnée possède une adresse unique, construite partout selon les mêmes niveaux :
Un historian et un lakehouse répondent à des besoins différents ; imec les conserve donc tous deux en les séparant clairement. Les responsables des installations ont besoin de réponses en quelques secondes, tandis que les analystes et les data scientists ont besoin d'un historique étendu couvrant tous les domaines.
La différence est réelle. Un rapport Power BI basé sur l'historian (DirectQuery) affiche des données en direct avec environ 3 secondes de latence. La même vue sur le lakehouse (Direct Lake) traite environ 40 millions de lignes, avec une latence d'environ 42 minutes. Chacun a sa place : la réactivité pour les opérations, l'historique pour l'analyse. Pour en savoir plus, consultez notre article de blog Still need a data historian in the age of data lakes?
Le côté OT s'arrête à Kafka, avec des données modélisées et contextualisées. Ce que la plateforme cloud en fait relève de ses propriétaires, et chaque consommateur reçoit le même flux.
Comme le broker d'entreprise se trouve dans la DMZ, l'OT reste protégé et l'IT dispose d'une seule porte gouvernée. De l'autre côté, la plateforme de données d'imec sur Microsoft Azure utilise Databricks pour l'analyse et l'IA, et Power BI pour le reporting.
Des données énergétiques détaillées sur la fab et les installations sont désormais accessibles à tous ceux qui en ont besoin. Une question comme « Quel est le coût énergétique de production de cette plaquette ? » devient possible. Ce n'était pas le cas avant.
Les incidents sont résolus plus vite, avec une vision claire de leur impact. Des questions comme « Quel est l'effet d'une variation de 0,2 K de l'eau de refroidissement sur la qualité des plaquettes ? » peuvent désormais être étudiées à travers les domaines.
Des tableaux de bord basés sur l'historian, avec quelques secondes de latence, pour ceux qui pilotent le site.
Les nouveaux outils et utilités s'intègrent dès le premier jour au même modèle, à commencer par FAB4 à Louvain et la nouvelle fab à Málaga.
« Avec plus de 15 000 équipements répartis sur cinq domaines très différents, concevoir chaque intégration à partir de zéro n'aurait jamais pu passer à l'échelle. En définissant un modèle et un schéma uniques, puis en les répétant, la montée en charge est devenue un exercice reproductible plutôt qu'une série de projets. Nos données énergétiques sont désormais accessibles à chaque responsable d'outil et d'installation, et nos nouvelles fabs seront prêtes pour les données dès le premier jour. »
Votre paysage OT grandit domaine par domaine, ou site par site ? Nous vous aidons à définir le modèle et le schéma une seule fois, pour que chaque nouvelle ligne, chaque domaine ou chaque site soit une répétition, pas un nouveau projet.
.jpg)
