Data Modeling
You know this best: Production is always unique. Just as every machine, every piece of equipment, and every station serves a specific purpose, the same is true for machine data. Raw data that is already available in the machine and serves as the basis for evaluations was, in most cases, not originally designed with the goal of later data analysis in mind. And there isn't THE best form of modeling, because that, too, depends on what the data will ultimately be used for.
For this reason, the onboarding process always begins with the question of how data can be transferred from the control level to the analysis level using a process that is as repeatable as possible.
Sound complicated? Don't worry. In most cases, we’ve already made the data from the first machine or system available during the first workshop. Good data modeling therefore doesn’t take weeks and can also be done iteratively. With our experience from hundreds of connected machines and large-scale systems, we’ll help you find the best way to present your data.
To provide an initial overview, we will first introduce some of our own terms that are relevant in the context of data modeling with Bytefabrik.
What makes a good data model?
Good data modeling translates technical signals into information that can be used for business purposes. A facility is not merely viewed as a list of data sources, but as a model consisting of assets, stations, activities, products, statuses, and notifications.
A good model answers four questions:
- Which physical unit provides the data?
- Which product, workpiece, or order is affected?
- Which process step or machine status is being described?
- What metric or analysis should result from this?
In the IoT Data Hub, raw data is integrated as data streams and is simultaneously available as a continuously updated dataset. Assets describe the shop floor structure and link data sources, dashboards, pipelines, and analytics to machines, lines, or stations.
For Manufacturing Insights, raw data is then converted into standardized reports. These reports make analyses comparable: For example, a production report can be used for equipment analysis, process analysis, OEE, and AI Copilot.
The most important modeling rule: Raw data may remain specific to its source; analyzed data must be stable, have technical names, and be comparable across systems.
It all starts with the raw data
For many analyses using Bytefabrik, only the raw data from the PLC is available at the outset. Commonly used protocols include the vendor-neutral OPC UA or a specific PLC such as a Siemens S7. Raw data can be retrieved continuously from the control system at fixed intervals (e.g., every second or at a higher resolution) and then transformed for more advanced analyses.
Metadata as a descriptive layer
We refer to metadata as data that describes the actual data and provides additional context. Metadata can be of a more technical nature (e.g., describing the data type, semantics, or range of values) or of a domain-specific nature (e.g., additional information about the machine or the process).
Technical Reports
We use protocols to describe processed data structures that are immediately available to the analysis system. To ensure the structure is as standardized as possible, we have already defined data models for specific analysis requirements.
In Bytefabrik, for example, the following predefined data structures are available:
- The production log links manufactured parts, process steps, quality, and timing.
- The machine state log records production times, downtime, and other system statuses.
- The event log standardizes errors, alarms, and warnings.
- KPI models define how these logs are used to generate meaningful metrics.
When onboarding a new plant, the main task is to define the transformation of raw data into these stable technical logs.