HighByte Intelligence HubDemo video
In the real HighByte interface, on a cement-plant demo project: connections, models, pipelines, the Unified Namespace and use cases. English narration and subtitles, 10 minutes.
What the video covers
The film starts with the problem: in a cement plant the kiln, the mills, the energy meters, the laboratory and the maintenance records each sit in their own system, and wiring them to each other point to point means one more script to write and maintain for every connection. It then introduces HighByte Intelligence Hub in four steps: connect the data, model it, process it in pipelines, and publish it.
Most of the film is the real HighByte interface running on a demo project: OPC UA, REST and SQL connections, equipment models and parameterized instances, the Unified Namespace and its live client, pipelines built from ready-made stages and JavaScript, conditions and lookup tables, a closed-loop pipeline that writes a result back to the PLC, the Modeling Agent and the MCP server, and project backup and settings.
The last chapters show five use cases (predictive maintenance, energy cost, quality, alarm management and open data) and what changes at enterprise scale: central hub, high availability, Git version control, audit log, role-based permissions and SAML or LDAP sign-in.
The demo project in the video
- Scenario
- A cement plant: the Kızılırmak Çimento, Kırıkkale demo project
- Connections
- 16: two OPC UA PLCs, MQTT, a REST service, four SQLite databases and file sources
- Configuration
- 28 models, 31 instances, 29 pipelines, 5 conditions
- Version shown
- HighByte Intelligence Hub 4.5.2
The plant, its names and the values shown are a demo scenario, not a customer installation. The screens are the real HighByte interface.
Transcript
The full narration, by chapter. Select a time to jump to that point in the video.
Read the full transcript
The problem: scattered plant data
In a cement plant, data never stops. The kiln, the mills, the energy meters, the laboratory, the maintenance records… Each one sits in its own system and speaks its own language. So who will deliver this data to the right person, reliably and in a form that makes sense? The answer is HighByte Intelligence Hub: an industrial DataOps platform.
The cost of point-to-point integration
In most plants, systems are wired to each other one by one, point to point. Every new connection means another script that has to be written and maintained. When a source changes, the chain breaks. And the same temperature reading goes by five different names in five different systems. In the end, teams lose their time trying to understand the data instead of using it.
What is HighByte?
HighByte is a data infrastructure that sits between the machines on the shop floor and the systems across the business. It runs inside the plant, at the edge. It connects the data, models it, gives it meaning, and delivers it in the same form to everyone who needs it. First, it connects: OPC UA, MQTT, REST, databases and files. And it does so without writing code. Then it models. For each type of equipment, a standard structure is defined just once. Next, pipelines process the data. They filter, calculate, enrich, and make decisions based on conditions. Finally, it publishes: to the Unified Namespace, to the cloud and to databases. When we want, we can even write data back to the shop floor. So the data becomes standardized in one place. The same model works unchanged on a hundred machines. And it is built not by software developers, but by the engineers who know the process.
Example project: Kızılırmak Çimento, Kırıkkale
Now let's see this in a realistic example: Kızılırmak Çimento, Kırıkkale plant. The whole line, from raw material to packaging, is brought together in a single HighByte project: two OPC UA servers, MQTT, REST, four databases and files.
Interface: project overview and connections
This is HighByte's browser-based interface. The project has sixteen connections, twenty-eight models and twenty-nine pipelines, and all of them are running healthy. The Connections section shows two OPC UA PLCs, a REST service, four SQLite databases and file sources. We open the burning PLC. All of the kiln's tags are defined as inputs. When we hit Test, we immediately see the kiln's live values.
Models and instances
In the Models section, we define the structure of the equipment once. The kiln model is made up of groups such as feed, drive, burning zone and flue gas. Models can also be derived from one another: shared attributes stay in the base model, and each piece of equipment adds only what is specific to it. An instance, in turn, binds the model to real data. Each attribute is mapped to the matching tag in the PLC. When we test it, we get an orderly, structured output that carries quality information. Thanks to parameters, a model works like a template. In the Energy Panel instance, you only need to change the panel parameter: the same definition attaches to the main incomer, the kiln or a mill. Inputs take parameters too. A REST request, a SQL query or an MQTT topic can be applied to dozens of assets with a single definition.
The Unified Namespace (UNS)
Instances are published in the Unified Namespace, in order: enterprise, plant, area and equipment. In the UNS client, we watch the data coming from the kiln live, inside this hierarchy.
Pipelines: stages, JavaScript and testing
Pipelines define the path the data takes. This one extracts the vibration data of the kiln drive motor, splits it into windows and analyzes it. It writes the result to the namespace, to a database, and to maintenance and enterprise systems. How many times it has run, and whether it has failed, is visible here too. When needed, you can write your own JavaScript in between. Here, a moving average, slope, ISO zone and health score are calculated for the vibration data. But most jobs don't need code. The stage library has triggers, filters, buffers, conditional branching, loops, and read and write stages ready and waiting. Pipelines can also call each other. Thanks to the Callable trigger and the Subpipeline stage, one pipeline uses another like a function and gets its result back. Even lookup tables can be fed by a pipeline. The equipment fault table takes its data from a pipeline running in the background, and keeps it cached for one minute. The Usage tab shows every connection: which inputs this pipeline reads from, and which outputs it writes to. You can see the impact of a change before you make it. With the Test tab, you can send sample data into the pipeline and watch the result right away.
Closed loop, conditions and lookup tables
The closed-loop pipeline collects data, produces a decision, and writes the result back to the PLC over OPC UA. So data doesn't only flow upward. We can write back to the shop floor too. Conditions are the foundation of event-based operation. For example, here is a condition that kicks in when the burning-zone temperature exceeds fifteen hundred degrees. Lookup tables, in turn, translate an alarm code into the matching action and notification details.
Modeling Agent, MCP, project and settings
The Modeling Agent speeds up creating models, inputs and instances with AI assistance. If you like, you can also expose pipelines to AI agents as tools. HighByte offers an MCP server for this; we keep it switched off in this project. On the administration side, the Project section exports and imports the entire configuration, and can even back it up to a Git repository and version it. In Settings, enterprise features such as the central hub, automatic backup, secrets, variables and certificates are gathered in one place.
Use cases
So what can you do with this? Let's look at a few example scenarios. First, predictive maintenance. Motor vibration is monitored continuously; when a threshold is exceeded, a record is opened automatically in the maintenance system. Second, energy cost. Meter data and the market price are combined, and the energy cost per ton is calculated in real time. Third, quality. When a laboratory result arrives, a fine-tuning recommendation is calculated and the value is written straight to the PLC. Fourth, alarm management. A condition triggers, a lookup table turns the alarm into an action, and a notification goes to the right person. Fifth, open data. From the same model, cloud platforms, analytics tools and AI applications receive clean, consistent data. The same approach scales from a single plant to many sites. Adding a new source doesn't break the others.
Deep dive: enterprise scale
So what changes at enterprise scale? The architecture stays the same; only the layers multiply. You define the model just once. Thanks to parameterized instances, the configuration doesn't grow, even as the number of panels or silos increases. You keep pipelines small and single-purpose: one collects the data, one calculates, one distributes. Each one is tested separately and reused. You start with the ready-made stages. When a custom calculation is needed, JavaScript or JSONata takes over; global functions are written once and used in every expression. Hubs at remote sites connect to a central hub. Configuration is monitored from one place, and namespaces are merged. High availability, version control with Git, an audit log, role-based permissions, and SAML or LDAP authentication come along with it. If the target connection drops, data is buffered to disk and delivered when the connection returns.
Summary
In short: data is connected once, modeled once, and reaches everywhere with the same meaning. For engineers, this means parameterized templates, the flexibility of JavaScript, debugging, and version control with Git. For managers, it means a data infrastructure that is monitored from a single screen, works the same way at every site, and is AI-ready and manageable. Teams spend their time designing data instead of writing integration code.
ASP Dijital
ASP Dijital, as HighByte's regional distributor, is by your side, from installation to modeling, from training to support. Let's make your plant's data useful, together.
Related reading
Let’s take the first step with HighByte together
Tell us where you are and what you want to achieve, and we will outline the right scope and pilot plan. Our team replies within 24 hours.