We designed one repeatable IT/OT pattern for five OT domains, from cleanroom tools to warehouses.
We built a Unified Namespace that gives more than 15,000 support assets one address and one meaning.
We streamed modelled, contextualised data from the plant floor into imec's cloud data platform.
imec runs some of the most advanced cleanrooms in Europe. More than 250 cleanroom tools are supported by over 15,000 assets for process, HVAC, gases, power and safety systems. These assets live in five very different OT domains: the fabs (FAB), the facilities (FAIN), the laboratories (LAB), the offices and the warehouses. Each domain has its own vendors, protocols and generations of equipment, from semiconductor tools with standardised and proprietary interfaces to classic DCS and PLC systems and IT-style building systems.
Over the years, the data got locked inside those systems. Every new use case came with its own stack and its own point-to-point integration, and every integration was a project of its own. A cross-domain view, such as energy use across the fab and the facilities, was hard to get.
With new cleanrooms on the way, FAB4 in Leuven and a new fab in Málaga, imec saw the moment to do it right from the start. They wanted to make energy data available to every tool and facility owner, not just one specialist, prepare their operational data for AI, and stop paying for point-to-point integrations at the scale of 15,000 assets.
Together with imec, we designed one target architecture that is repeated per domain: an edge gateway and a domain broker for each domain, a shared historian, and an enterprise broker in the DMZ that streams into imec's cloud data platform. A Unified Namespace gives every data point one address and one meaning, from site down to tag.
The domains publish once, and every consumer subscribes. Operations teams read live data from the shared historian in seconds, while the same modelled stream feeds Azure, Databricks and Power BI for analytics and AI. New tools, utilities and even new fabs land on the same pattern from day one. Adding a domain or a fab now means repeating the pattern, not designing a new integration.
Fueled by
imec and Coretecs go back a long way: we've worked side by side since our very first day, and imec's facilities already run on the automation library we co-created. For this project, our scope ran from sensor to Kafka: everything on the OT side, up to the point where modelled, contextualised data enters imec's cloud data platform.
The journey took about two years. The architecture was designed and the first domain went live in 2024. In 2025 the historian became a shared service, the Kafka stream to Azure went live, and Databricks and Power BI were connected.
Connecting the first machine is never the problem. Repeating it across a hundred systems, five domains or several sites is. The same signal easily has five different names: FT_201.PV in one system, Flow_lmin or DB40.DBD12 in the next.
That's why we design model-first. We start from what the business needs to know, define how it's calculated, then define the information model that every asset has to provide. Only then do we look at where the data comes from today.
Take a question like "Which tool uses the most energy per hour in production, per shift?". The logic is the sum of active power over time, split by tool state. So the model says that every tool provides a tool_id, active_power_kW, tool_state and shift_id. The tool state comes from the fab tool via SECS/GEM, the power from a facility meter via Modbus, and the shift calendar from the MES. Three vendors may call the power signal PWR.ACT_KW, DB12.DBD40 or Meter7/kW: it's mapped once, at the source, onto the same model attribute. (Illustrative example.)
The people who know what a signal means work at the plant. By adding the context there, once, it travels with the data to every consumer.
Every domain gets the same building blocks:
On site, the brokers and gateways run on Red Hat OpenShift. The brokers are HiveMQ, and the edge layer combines the right tool per domain, including Ignition, Litmus and Siemens.
The Unified Namespace gives imec a single, structured, real-time picture of the campus over MQTT. Every data point has one address, built from the same levels everywhere:
A historian and a lakehouse solve different problems, so imec keeps both and splits them clearly. The people running the facilities need answers in seconds. Analysts and data scientists need long history across all domains.
The difference is real. A Power BI report on the historian (DirectQuery) shows live data with about 3 seconds of latency. The same view on the lakehouse (Direct Lake) works through some 40 million rows, with a latency of around 42 minutes. Each has its place: seconds for operations, history for analytics. More on this in our blog Still need a data historian in the age of data lakes?
The OT side ends at Kafka, with modelled and contextualised data. What the cloud platform does with it is up to its owners, and every consumer gets the same stream.
Because the enterprise broker sits in the DMZ, OT stays protected and IT gets one governed door. On the other side, imec's data platform on Microsoft Azure uses Databricks for analytics and AI, and Power BI for reporting.
Granular energy data across the fab and the facilities is now available to everyone who needs it. That makes a question like "What is the energy cost of producing this wafer?" possible to answer. It wasn't before.
Incidents are resolved faster, with clear visibility of their impact. Questions like "How does a 0.2 K change on the cooling water facility affect wafer quality?" can now be investigated across domains.
Historian-backed dashboards with seconds of latency, for the people who run the plant.
New tools and utilities land on the same pattern from day one, starting with FAB4 in Leuven and the new fab in Málaga.
"With more than 15,000 assets across five very different domains, designing every integration from scratch was never going to scale. By defining one model and one pattern, and repeating it, scaling became a repeatable exercise rather than a series of projects. Our energy data is now available to every tool and facility owner, and our new fabs will be data-ready from day one."
Is your OT landscape growing domain by domain, or site by site? We help you define the model and the pattern once, so every new line, domain or site is a repeat, not a new project.
.jpg)
