The digital twin and the management shell already offer enormous advantages in industrial production today. In this interview, Kai Schwermann, founder and CTO of bill-X GmbH, explains how crucial the connections between individual assets are and how these connections form a digital ecosystem that enables production to be optimized and operated more energy-efficiently.
7 min Lesezeit, aktualisiert am 13.03.2026
Content
After reading this article, you will know:
How digital twins and connected assets can be used to make production processes more transparent and optimize them.
How mapping connections between machines and components creates a digital ecosystem for industry.
How software solutions like ActiveDB link machines, data, and asset capabilities to improve maintenance, control, and efficiency.
To explain this, I need to go back a bit and talk a little about the history of bill-X. After completing my computer science degree in the 1990s, I founded an internet service provider and set up email addresses, firewalls, and web servers. Naturally, I had to bill for all the services I provided. To do this, I programmed the necessary software—essentially the predecessor to our current billing software—which allowed these email addresses and web servers to be automatically requested, set up, and billed.
Well, when I process an invoice, I first need to know what I have. So the billing system also managed the customers’ entire inventory. This allowed us to track exactly which assets were available, from the components of the PCs used to the RFID chips in the cafeteria cards. Of course, I also have access to the generated data. But what’s far more important is the connection between these assets.
For example, if I know how these devices are connected to one another—that is, if I can determine which network cards on which computers are connected to which switches, and which IDs those switches have—I can map out and optimize the entire topology of this infrastructure. And that has now evolved into an Industry 4.0 solution with ActiveDB.
That’s right, but the truly important benefit for our industrial customers isn’t just about asset management. It’s about more than simply creating a bill of materials that shows everything a company operates. We want to illustrate how everything on the shop floor is interconnected in the real world. Back then, I told my apprentice, “We want to map the world.” He looked at me with a pretty confused expression.
Today, you’d call that a massive digital twin. A few years ago, when I said I wanted to eventually reach the speed and complexity needed to replicate a brain using a neural network, people laughed at me. After all, neurons are just interconnected and have simple functions. I could replicate that in ActiveDB. Of course, not today, because there aren’t any server systems yet that could handle that. But today, hardly anyone laughs at that anymore; many tend to agree with me that it would be possible.
For us, this was a logical step after we realized that we already knew two important things:
First, what assets actually exist, and second, how they are connected. The third important point was that these assets also have capabilities. And we can also map and integrate these capabilities through our software. Essentially, more than ten years ago, we created a digital ecosystem based on digital twins before we even knew there was a need for it. We called it an operating system for digital twins.
Yes, we did that without really knowing exactly what the connected devices are capable of. Let me illustrate this with a practical example, such as the management of e-scooters. Of course, I need to track who rode where, when, and for how long. But beyond that, scooter maintenance is also important—such as battery levels and overall technical condition. These connections and the performance data alone create a digital ecosystem.
At first, the software was used solely for billing, and contact with the industrial sector came about rather by chance through partner companies. After all, it hardly matters what our software manages. It can be used just for billing, but it can also connect and control machines, as well as highlight process and control issues. And not just as a Software-as-a-Service solution from the cloud, but also locally and self-sufficiently in a car or a battery storage system, completely independent of the company’s IT infrastructure. Ultimately, however, it is still not a specific industrial solution that we developed specifically for a particular requirement.
You could put it that way. It handles the integration of a company’s own assets and capabilities with the underlying billing systems. This allows us to map the entire lifecycle across the value chain—from the input of raw materials to marketing by wholesalers—using our tools. It doesn’t matter how many third-party systems are already in use. Since we “only” establish the connections between data streams, we’re basically nothing more than a kind of “positive data octopus.” That’s what sets us apart from other billing software providers, who often can only tell you how much revenue has been generated. We can tell you exactly how that money was earned. All thanks to our living digital twins.
Imagine an engine that comes with its own data—such as a manual and CAD drawings. We can store this data, link it to other assets, and analyze it to determine the engine’s capabilities. This is precisely what matters, because essentially, the engine itself tells us what it can do. This is still far from commonplace today.
Through intelligent links to other assets and additional apps, we can then enable the engine, for example, to notify service personnel on its own in the event of a failure or to reorder spare parts. So I can add new capabilities to the engine regardless of the manufacturer, thereby making it a living part of the ecosystem. This is precisely where the management shell becomes important.
Yes, because ultimately, administrative shells are a collection of data. The specific data involved is determined by the AAS submodels. More than ten years ago, we had to painstakingly assemble our digital twins—which weren’t called that back then—from individual components such as product name, voltage, network, and many other pieces of information. Today, I can handle all of this quite easily using submodels that automatically provide the data. But what’s far more important is that these submodels are already interoperable, allowing different participants in the digital ecosystem to add capabilities to the engine via submodels. For example, the engine can send a message to maintenance to get help on its own in the event of a malfunction. We could even theoretically write software for engine management using smaller software applications and submodels without knowing what kind of engines are involved. And we do this without having to overhaul the entire software landscape. We simply integrate the third-party systems via intermediate applications.
We think in terms of the whole picture. That’s what sets our approach apart from traditional methods, such as simple databases. With those, I have to know exactly which assets exist and what capabilities they have. We’ve flipped this approach and look at the connections between the assets, thereby figuring out what’s where and what it can do. We simply want to map the world. Any additional functionalities we need, we add via submodels, for example. This is how we bring the digital twins of the assets to life. And with each additional submodel, I have to worry less about domain-specific peculiarities because I can rely on standardized building blocks certified by the IDTA. Ultimately, I can also make my production more resilient using these digital twins.
When we look at traditional production processes, for example in the chemical industry, the various production steps and associated workflows are hard-coded into the PLC. Production then runs with millisecond precision, but this lacks flexibility. If a different formula needs to be run, the PLC must first be laboriously reprogrammed. With ActiveDB, I first connect all field-level sensors and actuators as digital twins and use them to build larger digital twins of the individual subsystems—such as the reactors—which I then network together. I can then implement recipe changes more easily via the digital twin. Even if the measured values no longer come in the correct format—for example, now in Kelvin instead of degrees Celsius and at a different sampling rate—that’s not a problem. The software can also convert all measured units and deliver them at the desired sampling rate, which is a huge advantage for users. Replacing a device also becomes much easier. As soon as the sensor is removed, the connection in ActiveDB is terminated and the disconnection is documented. I can then simply reconnect the new device virtually in the software.
That’s exactly it. Some of our customers duplicate their digital twins so that the real production runs on one twin and a simulated version runs on the copy. Now both can be compared, and feedback loops can be incorporated. If the simulation indicates that the bread should be fully baked after two hours, this can be verified in the digital twin of the real machine.
Absolutely, because ultimately, energy management is simply about distributing and balancing energy across consumers and generators. That, in itself, is a dynamic system where some consume more at times and less at others, while others generate more at times and less at others—especially when renewable energy sources are involved. For one customer, we built—to use IDTA terminology—separate management shells for energy generation and energy consumption. If the customer knows that they want to use only green electricity for a specific production process, then they can, within their
Absolutely, because ultimately, energy management is simply about distributing and balancing energy across consumers and producers. That, in itself, is a dynamic system where some consume more at times and less at others, while others generate more at times and less at others—especially when renewable energy sources are involved. For one customer, we built—to use IDTA terminology—separate management shells for energy generation and energy consumption. If the customer decides, “For a specific production process, I want to use only green electricity,” they can track within their digital twins where and how much green electricity has been generated and distribute it automatically accordingly. This also allows them to precisely determine the carbon footprint of their products, since they know exactly where the energy for production came from. The whole system can also be used in reverse, as I can naturally determine what the product’s final carbon footprint should be to meet specific targets. Furthermore, the energy management of this production line itself can also be integrated as an application within ActiveDB.
That’s right. We know exactly how much electricity is being generated from which source, which allows us to integrate the entire energy management system into a higher-level energy management system as a digital twin. Then it’s no trouble at all to instruct the production system that the next batch must be produced with a carbon-neutral footprint. Based on the programming of the digital twins, the electricity is then distributed accordingly.
In fact, we can actively and fully transparently manage the product’s carbon footprint during production. And through intermediate applications or sub-models, the production machine can even request the necessary green electricity on its own. Once the product is finished and shipped, we naturally also pass on the energy and emissions data generated, so that a living digital twin is created here as well, which can be further maintained. None of this is fiction anymore; it’s already working today.
You need an uncomplicated interface and are still looking for a partner? Or is your project rather complex and your plan difficult? In both cases – perfect.
Use the contact form or just send us an email.
Our contact details:
bill-X GmbH
Liebigstraße 29
D-49074 Osnabrück
+49 541 71008-0
info@bill-x.de
