Der Digital Twin und die Verwaltungsschale bieten in der industriellen Produktion schon heute enorme Vorteile. Wie wichtig dabei die Verbindungen zwischen den einzelnen Assets ist und wie daraus ein digitales Ökosystem wird, mit dem sich die Produktion optimieren und energieeffizienter fahren lässt, erklärt Kai Schwermann,Gründer und CTO der bill-X GmbH, im Interview.
7 min Lesezeit, aktualisiert am 13.03.2026
Inhalt
Nach der Lektüre dieses Artikels wissen Sie:
Wie digitale Zwillinge und vernetzte Assets genutzt werden können, um Produktionsprozesse transparenter zu machen und zu optimieren.
Wie durch die Abbildung von Verbindungen zwischen Maschinen und Komponenten ein digitales Ökosystem für die Industrie entsteht.
Wie Softwarelösungen wie ActiveDB Maschinen, Daten und Fähigkeiten von Assets verknüpfen, um Wartung, Steuerung und Effizienz zu verbessern.
Dafür muss ich etwas weiter ausholen und ein bisschen was zur Historie von bill-X erklären. Ich selbst habe nach meinem Informatik-Studium in den 1990er Jahren einen Internetprovider gegründet und habe E-Mail-Adressen, Firewalls und Web-Server eingerichtet. Alle Leistungen, die ich dafür erbracht habe, musste ich natürlich auch abrechnen. Dafür habe ich dann eine entsprechende Software programmiert, quasi den Vorgänger unserer heutigen Abrechnungssoftware, mit der diese Mailadressen und Web-Server automatisch beantragt, eingerichtet und abgerechnet werden konnten.
Nun, wenn ich etwas abrechne, muss ich dafür zunächst erstmal wissen, was ich habe. Das Abrechnungssystem hat also gleichzeitig auch das komplette Inventar der Kunden verwaltet. Damit konnten wir dann sehr genau nachvollziehen, welche Assets vorhanden sind, von den Komponentender verwendeten PCs bis hin zu RFID-Chips in denMensakarten. Genauso habe ich natürlich Zugriff auf die generierten Daten. Das viel Entscheidendere ist aber die Verbindung zwischen diesen Assets.
Wenn ich beispielsweise weiß, wie diese Geräte miteinander verknüpft sind, also nachvollziehen kann, welche Netzwerkkarten welcher Rechner an welchen Switches hängen, die wiederum mit welchen IDs verbunden sind, kann ich die komplette Topologie dieser Infrastruktur abbilden und optimieren. Und daraus ist dann jetzt mit ActiveDB eine Industrie-4.0-Lösung geworden.
Richtig, der wirklich wichtige Nutzen für unsere Industriekunden liegt allerdings nicht in dieser reinen Asset-Verwaltung. Es geht um mehr als nur die Erstellung einer Bill of Materials, die zeigt, was Unternehmen alles betreiben. Wir möchten darstellen, wie die echte Realität auf dem Shopfloor miteinander verbunden ist. Damals habe ich zu meinem Lehrling gesagt „Wir wollen jetzt die Welt abbilden“. Da hat er mich ganz schön verwirrt angeschaut.
Heute würde man das einen riesengroßen digitalen Zwilling nennen. Als ich vor ein paar Jahren gesagt habe, ich möchte irgendwann mal die Geschwindigkeit und Komplexität erreichen, um mit einem neuronalen Netz ein Gehirn nachzubauen, wurde ich ausgelacht. Schließlich sind Nervenzellen auch nur miteinander verbunden und haben einfache Funktionen. Das könnte ich in ActiveDB nachbauen. Natürlich noch nicht heute, weil es noch keine Serversysteme gibt, die das bewältigen würden. Aber heute lacht kaum noch einer darüber, viele stimmen mir eher zu, dass das möglich wäre.
Für uns war das ein logischer Schritt, nachdem wir festgestellt haben, dass wir schon zwei wichtige Dinge wissen:
Zum einen, welche Assets es überhaupt gibt, und zum anderen, wie sie verbunden sind. Der dritte wichtige Punkt war, dass diese Assets ja auch Fähigkeiten haben. Und diese Skills können wir über unsere Software ebenfalls darstellen und einbinden. Im Grunde haben wir so vor mehr als zehn Jahren auf Basis von Digital Twins ein digitales Ökosystem geschaffen, bevor wir überhaupt wussten, dass es dafür einen Bedarf gibt. Wir haben es ein Betriebssystem für digitale Zwillinge genannt.
Ja, wir haben das gemacht, ohne wirklich zu wissen, was genau die eingebundenen Geräte können. Lassen Sie mich das an einem praktischen Beispiel verdeutlichen, wie z. B. der Verwaltung von E-Scootern. Natürlich muss ich abrechnen, wer wann wie lange wohin gefahren ist. Darüber hinaus ist aber auch die Wartung der Roller wichtig, wie der Akkustand ist und wie der allgemeine technische Zustand aussieht. Allein aus diesen Verknüpfungen und den Performance-Daten entsteht ein digitales Ökosystem.
Zunächst wurde die Software lediglich für die Abrechnung verwendet und über Partnerunternehmen kam eher zufällig ein Kontakt zur Industrie zu Stande. Denn am Ende ist es fast egal, was unsere Software verwaltet. Sie kann nur für die Abrechnung genutzt werden, aber auch Maschinen vernetzen und steuern sowie Prozess- und Steuerungsprobleme sichtbar machen. Und das eben nicht nur als Software-as-a-Service-Lösung aus der Cloud, sondern auch lokal autark in einem Auto oder einem Batteriespeicher, komplett unabhängig von der Unternehmens-IT. Am Ende ist es aber immer noch keine spezifische Industrielösung, die wir extra für eine spezielle Anforderung entwickelt haben.
So könnte man es sagen. Sie kümmert sich um die Vernetzung der eigenen Assets und ihren Fähigkeiten mit den Abrechnungssystemen, die dahinter liegen. So können wir den Lebenszyklus über die gesamte Wertschöpfungskette hinweg, vom Einspeisen des Rohstoffs bis zur Vermarktung durch Großhändler, mit unseren Tools abbilden. Dabei ist es auch egal, wie viele Fremdsysteme bereits im Einsatz sind. Da wir „nur“ die Verknüpfungen der Datenströme herstellen, sind wir im Grunde nichts weiter als eine Art „positive Datenkrake“. Das unterscheidet uns auch von anderen Herstellern von Abrechnungssoftware, die oft nur sagen können, wie viel Umsatz generiert worden ist. Wir können genau sagen, womit das Geld verdient wurde. Alles dank unserer lebenden digitale Zwillinge.
Stellen Sie sich einen Motor vor, der von sich aus schon Daten mitbringt, also z. B. ein Handbuch und CAD-Zeichnungen. Diese Daten können wir speichern, mit Links zu anderen Assets versehen und analysieren, um zu erfahren, welche Funktionalitäten der Motor hat. Genau das ist entscheidend, denn im Grunde sagt uns der Motor selbst, was er alles kann. Das ist heute noch absolut nicht selbstverständlich.
Durch intelligente Verknüpfungen mit anderen Assets und weitere Apps können wir den Motor dann z. B. in die Lage versetzen, bei einem Ausfall selbst das Service-Personal zu informieren oder Ersatzteile nachzubestellen. Ich kann dem Motor also unabhängig vom Hersteller neue Skills hinzufügen und ihn so zu einem lebendigen Teil des Ökosystems machen. Genau hier ist auch
Ja, denn am Ende sind Verwaltungsschalen eine Sammlung von Daten. Welche Daten das sind, entscheidet sich über die Teilmodelle der AAS. Vor mehr als zehn Jahren mussten wir unsere digitalen Zwillinge, die damals noch nicht so hießen, mühsam aus Einzelkomponenten wie Produktname, Spannung, Netzwerk und vielen weiteren Informationen zusammenbauen. Heute kann ich das alles ganz einfach über Teilmodelle lösen, die Daten automatisch bereitstellen. Viel wichtiger ist aber, dass diese Submodels bereits interoperabel sind und dadurch verschiedene Teilnehmer des digitalen Ökosystems dem Motor über Teilmodelle Skills hinzufügen können. Eben z. B., dass er sich im Störfall über eine Mitteilung an die Instandhaltung selbst Hilfe holen kann. Wir könnten über kleinere Software-Anwendungen und Submodels sogar theoretisch Software für eine Motorenverwaltung schreiben, ohne zu wissen, um was für Motoren es sich handelt. Und das machen wir, ohne dass die komplette Softwarelandschaft aufgeräumt werden muss. Wir binden die Fremdsysteme einfach über Zwischenanwendungen mit ein.
Wir denken um das Ding herum. Das unterscheidet unseren Ansatz von herkömmlichen Methoden z. B. reinen Datenbanken. Dabei muss ich genau wissen, welche Assets es gibt und welche Skills sie haben. Wir haben diesen Ansatz umgedreht und schauen auf die Verbindungen zwischen den Assets und finden so heraus, was wo ist und was es kann. Wir wollen eben die Welt abbilden. Alle Funktionalitäten, die wir zusätzlich benötigen, fügen wir z. B. über Submodels hinzu. So machen wir die digitalen Zwillinge der Assets lebendig. Und mit jedem Teilmodell mehr muss ich mir weniger Gedanken über domänenspezifische Eigenheiten machen, weil ich auf standardisierte und durch die IDTA zertifizierte Bausteine zurückgreifen kann. Im Endeffekt kann ich über diese so erstellten Digital Twins meine Produktion auch resilienter machen.
Wenn wir auf klassische Produktionsprozesse z. B. in der Chemieindustrie blicken, dann sind die verschiedenen Produktionsschritte und die dazugehörigen Abläufe hart codiert in der SPS programmiert. Dann läuft die Produktion auf die Millisekunde genau, aber flexibel ist das nicht. Soll eine andere Rezeptur gefahren werden, muss die SPS erst einmal aufwendig umprogrammiert werden. Mit der ActiveDB binde ich erst einmal alle Sensoren und Aktoren der Feldebene als digitale Zwillinge an und baue mir daraus größere Digital Twins der einzelnen Teilsysteme, z. B. der Reaktoren, zusammen, die ich dann miteinander vernetze. Rezepturänderungen kann ich dann über den Digital Twin einfacher durchführen. Selbst wenn dann die Messwerte nicht mehr in der richtigen Form einlaufen, z. B. jetzt in Kelvin statt Grad Celsius und in einer anderen Taktung, ist das kein Problem. Die Software kann auch alle gemessenen Einheiten umrechnen und in der gewünschten Taktung liefern, was für die Anwender ein enormer Vorteil ist. Auch ein Gerätetausch wird sehr viel einfacher. Sobald der Sensor ausgebaut ist, wird die Verbindung in der ActiveDB beendet und der Abbruch dokumentiert. Das neue Device kann ich dann in der Software einfach wieder virtuell verbinden.
Das ist es auch. Einige Kunden von uns duplizieren ihre Digital Twins, so dass in dem einen Zwilling die echte Produktion läuft und in der Kopie eine simulierte. Jetzt können beide miteinander abgeglichen werden und Feedback-Schleifen eingebaut werden. Wenn die Simulation sagt, das Brot müsste nach zwei Stunden fertig gebacken sein, kann das im Digital Twin der realen Maschine verifiziert werden.
Absolut, denn am Ende ist das Energiemanagement auch nur das Verteilen und Ausgleichen von Energie über Verbraucher und Erzeuger. Das ist an sich ja auch wieder ein lebendes System, in dem die einen mal mehr und mal weniger verbrauchen, während die anderen mal mehr, mal weniger erzeugen, gerade wenn erneuerbare Energiequellen im Spiel sind. Für einen Kunden haben wir, wenn man es in IDTA-Sprech sagen würde, eigene Verwaltungsschalen für die Energieerzeugung und den Energieverbrauch gebaut. Wenn der Kunde weiß, für einen bestimmten Produktionsprozess will ich jetzt nur Ökostrom einsetzen, dann kann er innerhalb seiner
Absolut, denn am Ende ist das Energiemanagement auch nur das Verteilen und Ausgleichen von Energie über Verbraucher und Erzeuger. Das ist an sich ja auch wieder ein lebendes System, in dem die einen mal mehr und mal weniger verbrauchen, während die anderen mal mehr, mal weniger erzeugen, gerade wenn erneuerbare Energiequellen im Spiel sind. Für einen Kunden haben wir, wenn man es in IDTA-Sprech sagen würde, eigene Verwaltungsschalen für die Energieerzeugung und den Energieverbrauch gebaut. Wenn der Kunde weiß, für einen bestimmten Produktionsprozess will ich jetzt nur Ökostrom einsetzen, dann kann er innerhalb seiner digitalen Zwillinge nachvollziehen, wo wie viel Ökostrom erzeugt worden ist und ihn entsprechend automatisiert verteilen. So kann er außerdem genau sagen, wie groß der CO2-Fußabdruck seiner Produkte ist, weil er ja genau weiß, wo die Energie für die Produktion hergekommen ist. Das Ganze ist aber auch umgekehrt nutzbar, denn ich kann so natürlich auch bestimmen, wie groß der CO2-Fußabdruck des Produkts am Ende sein soll, um bestimmte Werte einzuhalten. Darüber hinaus kann auch das Energiemanagement dieser Produktionslinie selbst wieder eine Anwendung in der ActiveDB sein.
So ist es. Wir wissen, welcher Strom in welcher Menge aus welcher Quelle erzeugt wird und können so ein ganzes Energiemanagement wieder als digitalen Zwilling in ein übergeordnetes Energiemanagement integrieren. Dann ist es überhaupt kein Akt, dem Produktionssystem zu sagen, dass die nächste Charge mit CO2-neutralen Fußabdruck gebaut werden muss. Basierend auf der Programmierung der Digital Twins wird der Strom dann entsprechend verteilt.
Genau wir können quasi den Product Carbon Footprint während der Produktion aktiv und vollkommen nachweisbar steuern. Und über die Zwischenanwendungen oder Teilmodelle kann die Produktionsmaschine dann sogar selbst z. B. den notwendigen Ökostrom anfordern. Wenn das Produkt fertig ist und ausgeliefert wird, geben wir die angefallenen Energie- und Emissionsdaten natürlich auch weiter, sodass hier wieder ein lebender Digital Twin entsteht, der weiter gepflegt werden kann. Das ist alles keine Fiktion mehr, es funktioniert schon heute.
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
