Intelligenter Kran: Steuerungssystem & Digitaler Zwilling
Mehr als nur Kranbau: Die technische Logik hinter Keludes eigenentwickeltem Steuerungssystem und der Digital-Twin-Plattform. In der Kranindustrie werden Steuerungssysteme und digitale Plattformen zunehmend zum entscheidenden Wettbewerbsfaktor.
In der Kranindustrie werden Steuerungssysteme und digitale Plattformen zunehmend zum entscheidenden Wettbewerbsfaktor. Während die meisten Hersteller noch auf Standardlösungen mit handelsüblichen SPS-Steuerungen und Fremd-HMIs setzen, verfolgt Kelude Schwerindustrie einen grundlegend anderen technologischen Ansatz – von der Hardware bis zur Software, von der Datenerfassung bis zum Digitalen Zwilling, alles aus eigener Entwicklung. Dahinter steckt kein Marketingkalkül, sondern die Erkenntnis, dass Standardlösungen bei den komplexen Betriebsbedingungen von Kranen an ihre Leistungsgrenzen stoßen.
Dieser Artikel beleuchtet die technische Logik der Kelude-Eigenentwicklung auf drei Ebenen: die integrierte Hard- und Softwarearchitektur des Steuerungssystems, die Modellierungs- und Vorhersagefähigkeiten der Digital-Twin-Plattform sowie die Integrationslösung der Datenplattform. Jede Ebene wird hinsichtlich Kosten, Leistung und Skalierbarkeit mit Standardlösungen verglichen.
Eigenentwickeltes Steuerungssystem: Industrie-PC + Echtzeit-Linux + eigene Algorithmen statt Standard-SPS
Digital-Twin-Plattform: Unity 3D + WebGL, POD-Reduktionsmodell, LSTM-Prädiktion
Die Digital-Twin-Plattform von Kelude Schwerindustrie dient nicht der reinen 3D-Repräsentation – ihr Kernwert liegt in drei Fähigkeiten: Visualisierung, präzise Berechnung und frühzeitige Vorhersage. Die zugrunde liegende Logik lässt sich als geschlossene Kette aus „Daten – Modell – Simulation – Entscheidung" beschreiben.
Visualisierungsebene: WebGL-Interaktion auf Basis von Unity 3D. Kelude setzt Unity 3D als Rendering-Engine ein und kompiliert die Szene in das WebGL-Format. Anwender benötigen keine Client-Installation – das vollständige 3D-Modell des Krans ist direkt im Browser verfügbar. Dieses Modell ist keine einfache CAD-Darstellung: Es bildet alle Bewegungszustände der Anlage in Echtzeit ab – Kranfahrposition, Laufkatzenposition, Hubhöhe und Pendelwinkel der Last werden per WebSocket vom Daten-Hub an das Frontend übertragen. Die Aktualisierungsrate beträgt 20 fps (50 ms Auflösung), die visuelle Latenz liegt unter 100 ms. Das Bedienpersonal in der Bodensteuerung sieht im Browser exakt dasselbe 3D-Szenario wie im Führerhaus.
Für eine schnelle Ladezeit im Browser hat das Entwicklungsteam umfangreiche Optimierungen vorgenommen: Die Modellpolygonanzahl wurde von 8 Millionen im Original-CAD auf 150.000 reduziert (unter Beibehaltung aller äußeren Merkmale, ohne unsichtbare Innendetails), Texturen nutzen das KTX2-Komprimierungsformat zur Reduzierung des Grafikspeichers, und der Animationscontroller arbeitet mit einem Zustandsmaschinen-Modell statt mit Frame-für-Frame-Animation. Die Erstladezeit liegt bei unter 4 Sekunden (bei 100 Mbit/s-Netzwerkverbindung).
Physikalische Simulationsebene: POD-Reduktionsmodell für Echtzeitsimulation. Die größte technische Herausforderung eines Digitalen Zwillings ist nicht die Optik, sondern die Rechengeschwindigkeit. Ein typisches Finite-Elemente-Modell des Hauptträgers eines 100-t-Brückenkrans umfasst über 300.000 Freiheitsgrade. Eine einzelne statische Berechnung mit kommerzieller FEA-Software (z. B. ANSYS, Abaqus) dauert 3–5 Minuten – für eine Echtzeitsimulation völlig inakzeptabel.
Keludes Lösung ist ein POD-Reduktionsmodell (Proper Orthogonal Decomposition). Der Grundgedanke ist einfach: Die Spannungsverteilung unter den meisten Betriebsbedingungen lässt sich durch eine Linearkombination weniger Basis-Moden approximieren. Das Entwicklungsteam berechnete mit ANSYS zunächst die strukturellen Spannungsfelder für 1.000 repräsentative Lastfälle (Kombinationen aus unterschiedlichen Lastpositionen, Lastgrößen und Laufkatzenpositionen). Mittels Singulärwertzerlegung (SVD) wurden die 15 Basis-Moden mit der höchsten Energie extrahiert – diese 15 Moden repräsentieren 99,2 % der kumulierten Energie, d. h. sie rekonstruieren den überwiegenden Teil der Informationen aus allen 1.000 Lastfällen.
Im Online-Betrieb interpoliert das System die aktuellen Lastbedingungen im 15-dimensionalen Raum und führt eine Linearkombination durch. Die Berechnungszeit für ein einzelnes Spannungsfeld wird auf 15–30 ms reduziert, die Präzisionsverlustkontrolle liegt unter 5 %. Damit kann der Digitale Zwilling bei jedem Hubvorgang das vollständige Spannungsfeld des Hauptträgers als Heatmap in Echtzeit aktualisieren – das Bedienpersonal sieht nicht mehr nur isolierte Dehnungsmesswerte einzelner Sensoren, sondern ein Gesamtbild des Hauptträgers mit der Frage „Wo wirkt welche Spannung, wo entsteht Ermüdung?"
Messdaten aus dem Praxiseinsatz: An drei 100-t-Brückenkranen wurden jeweils 16 faseroptische Dehnungsmessstellen (FBG) und 4 Beschleunigungssensoren installiert, die Datenerfassungsfrequenz beträgt 1 Hz. Das POD-Modell führt jede Sekunde eine vollständige Spannungsfeldberechnung durch und überlagert das Ergebnis auf dem Unity-3D-Modell. Das System läuft seit über 14 Monaten (Stand: Juni 2026) stabil und hat über 37 Millionen Berechnungen ohne eine einzige Divergenz oder Anomalie durchgeführt.
Prädiktionsebene: LSTM-Zeitreihenmodell für Restlebensdauervorhersage. Die höhere Fähigkeit eines Digitalen Zwillings liegt nicht im Verstehen der Gegenwart, sondern in der Vorhersage der Zukunft. Kelude ergänzt die vom POD-Modell gelieferten Spannungsfelddaten um ein Modul zur Lebensdauervorhersage bei Ermüdung auf Basis eines LSTM-Netzwerks (Long Short-Term Memory).
Die Eingangsmerkmale des LSTM-Modells umfassen: die vom POD-Modell berechnete maximale Vergleichsspannung am Hauptträger, die Anzahl der Spannungsspiele (extrahiert nach dem Rainflow-Zählverfahren), Mittelwert und Amplitudenverteilung des Lastkollektivs, die kumulierte Betriebszeit der Anlage sowie die Umgebungstemperatur. Die Ausgabe besteht aus der Restlebensdauer der kritischen Hauptträgerbereiche (ausgedrückt in Lastspielen) und einer Warnstufe (vier Stufen: grün/gelb/orange/rot). Das Modell arbeitet mit einem gleitenden Fenster von 720 Zeitschritten (entspricht 12 Stunden historischer Daten) und prognostiziert die Ermüdungsakkumulation für die nächsten 7 Tage.
Trainingsdatenquelle: Vor der Inbetriebnahme wurde das LSTM-Modell offline mit 12 Monaten historischer Betriebsdaten von 3 Versuchsprototypen trainiert (1,2 Millionen gültige Stichproben). Im laufenden Betrieb wird das Modell alle 24 Stunden automatisch inkrementell aktualisiert, um neue Daten in den Trainingssatz aufzunehmen und so Alterungstendenzen und Betriebsbedingungsänderungen zu berücksichtigen. In der Validierungsphase von Oktober 2025 bis Juni 2026 betrug der mittlere absolute prozentuale Fehler (MAPE) der 7-Tage-Vorhersage der Ermüdungsakkumulation am Hauptträger 8,3 %. Der Vorhersagehorizont bietet dem Wartungsteam ausreichend Zeit, Instandhaltungsmaßnahmen vor einer ungeplanten Stillstandszeit zu planen.
Darüber hinaus integriert die Plattform ein Vibrationsvorhersagemodul für das Getriebegehäuse des Hubwerks und die Motorlager. Durch die Merkmalsextraktion im Zeit- und Frequenzbereich (FFT + Hüllkurvenspektrum) des Beschleunigungssignals in Kombination mit dem LSTM-Modell können Innenring- und Außenringfehler der Lager 7–14 Tage im Voraus erkannt werden. An den 8 installierten Anlagen hat das Modell insgesamt 47 Frühwarnungen ausgegeben, von denen 43 durch Inspektionen vor Ort als echte Fehler bestätigt wurden – eine Warnungsgenauigkeit von 91,5 % bei einer durchschnittlichen Vorlaufzeit von 11,3 Tagen.
Datenplattform: OPC-UA/MQTT-Erfassung, Zeitreihendatenbank, API-Gateway
Das Steuerungssystem erzeugt Daten, der Digitale Zwilling konsumiert sie – die Brücke zwischen beiden bildet die Datenplattform. Die Architektur der Kelude-Datenplattform folgt einem dreistufigen Design – „Edge-Erfassung – Speicherung – Service-Ausgabe" – mit klarer technologischer Begründung auf jeder Ebene.
Edge-Erfassungsebene: OPC UA als Primärprotokoll, MQTT als Ergänzung. Auf der Anlagenseite läuft das von Kelude entwickelte Edge-Gateway „KruEdge" auf einem Industrie-PC im Schaltschrank und kommuniziert über OPC UA mit der KruControl-Laufzeitumgebung. Die Wahl von OPC UA ist klar begründet: natives Datenmodell (Übertragung semantisch angereicherter Daten statt roher Messwerte – z. B. „Hauptträger max. Vergleichsspannung/MPa/Messstelle FBG-03"), Sicherheitsverschlüsselung (X.509-Zertifikatsauthentifizierung + AES-256-Transportverschlüsselung) sowie automatische Nachübertragung historischer Daten bei Verbindungsunterbrechung. Das Gateway erfasst drei Datenkategorien: Betriebszustandsvariablen (Geschwindigkeit, Strom, Drehmoment und Position der drei Mechanismen Heben/Kranfahren/Laufkatze), Sicherheitsvariablen (Überlastsensor, Endschalter, Bremsenstatus) sowie strukturelle Gesundheitsvariablen (FBG-Dehnung, Beschleunigung, Temperatur) – insgesamt ca. 600 Datenpunkte mit konfigurierbarer Erfassungsfrequenz von 1–100 Hz.
Für ältere Anlagen ohne OPC-UA-Unterstützung (z. B. Modelle älter als 3 Jahre, teilweise mit Modbus-RTU-Protokoll) überbrückt das Edge-Gateway die Kommunikation über einen Modbus-zu-OPC-UA-Protokolladapter. Für wenige nicht zeitkritische Telemetriedaten (z. B. GPS-Position, Umgebungsfeuchte, Energieverbrauchsstatistik) wird MQTT mit einem Berichtsintervall von 5 Minuten verwendet, um die Datenlast auf der Steuerungsebene zu reduzieren.
Speicherebene: Hybride Speicherarchitektur auf Basis einer Zeitreihendatenbank. Bei kontinuierlicher Erfassung von 600 Datenpunkten mit 1–100 Hz erzeugt eine einzelne Anlage täglich ca. 1,5–5 GB Daten (abhängig von der Erfassungsdichte). Wenn 50 % der bei Kelude im Einsatz befindlichen Anlagen (ca. 200 Stück) an die Datenplattform angebunden werden, ergibt sich ein jährliches Datenvolumen von 100–360 TB. Herkömmliche relationale Datenbanken sind für diese Schreiblast offensichtlich nicht ausgelegt.
Keludes Speicherlösung ist eine zweistufige Hybridarchitektur: Die erste Stufe ist ein lokaler Cache – jedes Edge-Gateway ist mit einer 256-GB-NVMe-SSD ausgestattet und speichert die vollständigen Daten der letzten 30 Tage (ca. 45–150 GB pro Anlage). Bei Netzwerkunterbrechung gehen keine Daten verloren; nach Wiederherstellung erfolgt die automatische Nachübertragung. Die zweite Stufe ist eine cloudbasierte Zeitreihendatenbank – die Open-Source-Lösung TimescaleDB (PostgreSQL-basierte Zeitreihenerweiterung) wird auf einem privaten Server betrieben. Die Tabellenstruktur folgt einem Breitformat nach „Anlagen-ID + Zeitstempel + Messstellen-ID", die Zeitpartitionierung beträgt 72 Stunden. Gemessene Schreibleistung: Ein einzelner Knoten (8 Kerne, 32 GB RAM) verarbeitet stabil 240.000 Zeilen pro Sekunde; die 95-Perzentil-Abfragelatenz liegt unter 50 ms (Abfrage der vollständigen Daten einer einzelnen Anlage über 30 Tage).
Zur Reduzierung der Speicherkosten für historische Daten wurde eine Datenkomprimierungs- und Aggregationsstrategie implementiert: Rohdaten werden 90 Tage vorgehalten (für Fehleranalyse und Modelltraining); Daten zwischen 90 Tagen und 1 Jahr werden auf einen Wert pro Minute heruntergesampelt (Aggregation als Mittelwert + Maximum + Minimum); Daten älter als 1 Jahr werden auf einen Wert pro Stunde heruntergesampelt. Der Gesamtspeicherbedarf (Rohdaten plus zwei Aggregationsstufen) beträgt nur 12–15 % des ursprünglichen Datenvolumens.
Serviceebene: Einheitliches API-Gateway. Wer konsumiert die gespeicherten Daten? Das Digital-Twin-Frontend benötigt Echtzeitdaten, das Webportal historische Trendkurven, die mobile App Benachrichtigungen und Drittsysteme (z. B. MES oder ERP des Kunden) benötigen Schnittstellen – jeder Konsument hat andere Datenformate, Übertragungsprotokolle und Berechtigungsanforderungen. Kelude hat dafür das API-Gateway „KruGateway" eigenentwickelt.
KruGateway basiert auf dem Open-Source-Gateway Kong und wurde um industrielle Funktionen erweitert: einheitlicher Zugang für die vier Protokolle OPC UA, MQTT, HTTP REST und gRPC. Intern werden alle Daten in das Standard-JSON-Format überführt und anschließend an die Consumer verteilt. Die Berechtigungsverwaltung auf Gateway-Ebene erfolgt dreidimensional nach „Geräteebene + Datenebene + Funktionsebene“: Ein Kunde kann beispielsweise nur die zehn ihm zugeordneten Geräte einsehen (Geräteebene), ausschließlich Statusdaten abrufen, aber keine Steuerparameter ändern (Funktionsebene), und innerhalb der Statusdaten bleiben sicherheitsrelevante Sensordaten ausgeblendet (Datenebene). Darüber hinaus verfügt die Gateway-Ebene über integriertes Datenfluss-Controlling und Cache-Beschleunigung – bei hochfrequenten Anfragen des Digitalen Zwillings (20 fps Aktualisierung) werden die letzten drei Sekunden an Snapshot-Daten automatisch zwischengespeichert, sodass nicht jede Frontend-Renderung eine Datenbankabfrage auslöst.
Bis Juni 2026 verarbeitet KruGateway täglich etwa 2,8 Millionen API-Aufrufe, die Reaktionszeit liegt beim 95. Perzentil unter 15 ms, die monatliche Verfügbarkeit beträgt 99,97 %.
Ganzheitlicher Vergleich mit Standardlösungen: Kosten, Leistung, Skalierbarkeit
Die drei oben dargestellten technischen Ansätze beleuchten die zugrunde liegende Logik der selbst entwickelten Lösung von Kelude. Doch die endgültige Entscheidung über die Technologieauswahl trifft nicht das Entwicklungsteam, sondern das Management – und dessen Kernfrage lautet: Worin liegt der konkrete Vorteil dieser Eigenentwicklung gegenüber einer Standardlösung? Rechtfertigt der Mehrwert den zusätzlichen Aufwand an Personal und Ressourcen?
Die folgende Tabelle bietet einen quantitativen Gesamtvergleich entlang der drei Dimensionen Kosten, Leistung und Skalierbarkeit:
| Vergleichskriterium | Kelude-Eigenentwicklung | Branchenstandardlösung | UnterschiedAusladung |
|---|---|---|---|
| Gesamte Hardwarekosten(pro Einheit) | 1.8~2.510.000 CNY | 2.5~410.000 CNY | niedrig20%~40% |
| Softwarelizenzgebühr(10pro Einheit) | ≈0 | 3~810.000 CNY | nahezu null Lizenzkosten |
| Steuerungsrechenleistung | ~1210.000DMIPS(i7-12700TE) | ~0.4~1.510.000DMIPS | hoch8~30fach |
| RegelzyklusGenauigkeit | 5μsJitter im Bereich(PREEMPT_RTharte Echtzeit) | ±1~5msJitter im Bereich | Genauigkeithoch100~1000fach |
| PendeldämpfungLeistung(RestPendelwinkel) | <0.3°(Volllast,vollständigBetriebsbedingungenselbstadaptiv) | 0.5°~1.5°(erforderlichManuellParameterabstimmung,Betriebsbedingungenempfindlich) | Verbesserung40%~80% |
| Digitaler ZwillingEchtzeitfähigkeit | 20fpsvollständigSpannungFeld-Simulation,Latenz<100ms | keine(Branchenweit fehlt es an Echtzeit-Digital-Twin-Fähigkeit) | von Null auf Eins |
| vorausschauende WartungBranchenweit fehlt es an Echtzeit-Digital-Twin-Fähigkeit | LSTMModell,LagerFrühwarnungim Voraus7~14Tage,Genauigkeit91.5% | Schwellwertalarm(Überschreitung eines Einzelwerts) | qualitativer Sprung |
| Systemerweiterbarkeit | DockerContainer-basierte Bereitstellung,OTADifferenzAufrüstung,Unterstützung privater Algorithmus-Integration | Funktionserweiterung herstellerabhängigFirmware-Update,keine Integration eigener Algorithmen möglich | vollständig offen vs. geschlossenes Ökosystem |
| Datenanbindungsfähigkeit | OPC UA+MQTT+Modbusvoll kompatibel,Unterstützung von DrittsystemenRESTAnbindung | erfordert zusätzlich Industrie-Gateway oderSCADA-System | integrierte Lösung vs. Flickwerk-Lösung |
Aus dem obigen Vergleich lässt sich eine klare Logik ableiten: Die „Grenze" der universellen SPS-Lösung ist kein Preisproblem, sondern ein Architekturproblem. Ihre Rechenleistung, Echtzeitfähigkeit, Offenheit und Erweiterbarkeit begrenzen sie auf die Ebene der „speicherprogrammierbaren Steuerung" – sie kann keine höherwertigen Funktionen wie intelligente Algorithmen, digitale Zwillinge oder industrielle Big-Data-Analysen tragen. Die Kelude-Lösung mit Industrie-PC und Echtzeit-Linux senkt im Kern einen Hochleistungs-Industriecomputer auf die Rolle einer Steuerung herab – überschüssige Rechenleistung wird gegen Entwicklungsflexibilität und zukünftigen Erweiterungsspielraum getauscht.
Natürlich hat dieser Ansatz auch seinen Preis. Der größte Kostenfaktor ist die Entwicklungsinvestition: Von der Projektfreigabe 2021 bis zur Serienproduktion 2024 wurden in die KruControl-Plattform insgesamt über 32 Millionen CNY (ca. 4,07 Mio. EUR) investiert, mit einem Aufwand von über 120 Personenjahren. Für einen mittelständischen Fertigungsbetrieb mit einem Jahresumsatz von einigen hundert Millionen CNY ist das ein in der Bilanz durchaus „sichtbarer" Betrag. Der zweite Kostenfaktor ist das Lieferkettenmanagement – die Beschaffung der Komponenten für Industrie-PCs, die Leiterplattenbestellung kundenspezifischer Mainboards (durchschnittlich 12–16 Wochen) und die Anpassung und Verifikation des Echtzeit-Linux-Kernels sind erheblich komplexer als der Kauf fertiger SPS-Steuerungen.
Das Management von Kelude ist sich jedoch über diesen technologischen Weg im Klaren: An dem Wendepunkt, an dem sich die Kranbranche vom „Wettbewerb um Größe" zum „Wettbewerb um Technologie" verlagert, wird das „Ausreichende" der universellen SPS zunehmend zum „Nicht-Ausreichenden". Statt zu warten, bis Wettbewerber mit eigenen Lösungen den Premiummarkt erobern, investiert man lieber selbst drei Jahre in den Aufbau eines technologischen Burggrabens.
Fazit
Zurück zum Titel dieses Artikels: Mehr als nur Kranbau. Kelude Schwerindustrie fertigt seit zwanzig Jahren Krane – doch was dieses Unternehmen wirklich von der Konkurrenz unterscheidet, ist nicht die maximale Tragfähigkeit oder die Komplexität der Aufträge, sondern das, was im Inneren des Krans „unsichtbar" bleibt: jede Zeile Code im Steuerungssystem, jede Basisfunktion des digitalen Zwillings und jede Datenpipeline der Datenplattform – alles selbst entwickelt.
Die universelle SPS-Lösung ist zweifellos ausgereift und zuverlässig, doch sie definiert zugleich die Leistungsgrenze des Krans. Kelude hat sich entschieden, diese Grenze mit IPC + Echtzeit-Linux zu durchbrechen, den digitalen Zwilling durch POD-Reduktionsmodelle vom Demonstrationswerkzeug zum Engineering-Werkzeug zu machen und mit einer eigenen Datenplattform Gerätedaten in Unternehmenswerte zu verwandeln. Diese drei Bausteine bilden zusammen das technologische Fundament von Kelude Schwerindustrie im Bereich intelligenter Krane.
Dieser Weg war nicht schnell – von der Initiierung 2021 bis zur Serienproduktion 2024 vergingen mehr als drei Jahre; und er war nicht günstig – 32 Millionen CNY (ca. 4,07 Mio. EUR) Entwicklungsinvestition sind für ein Fertigungsunternehmen keine Kleinigkeit. Doch im Kelude-Team herrscht Konsens: Ein technologischer Burggraben ist das einzige Asset, das kein Preiskampf wegspülen kann. Was mit universellen SPS-Lösungen nicht möglich ist, kann Keludes Eigenentwicklung leisten – genau darin liegt die Differenzierung.
Häufige Fragen
F: Was ist der grundlegende Unterschied zwischen Keludes eigenentwickeltem IPC + Echtzeit-Linux-Steuerungssystem und einer universellen SPS?
A: Der grundlegende Unterschied liegt in der Offenheit der Systemarchitektur und der Rechenleistungsobergrenze. Bei einer universellen SPS werden Hard- und Software vom Hersteller geschlossen definiert; der Anwender kann nur innerhalb des vom Hersteller vorgegebenen Rahmens programmieren (z. B. Kontaktplan, SCL), keine eigenen höherwertigen Algorithmen ausführen, und die Rechenleistung ist auf stromsparende ARM-Prozessoren begrenzt. Keludes IPC-Lösung verwendet Intel-x86-Prozessoren, bietet die 8- bis 10-fache Rechenleistung einer High-End-SPS, läuft mit dem PREEMPT_RT-Echtzeit-Linux-Kernel und kann beliebigen C++/Python-Algorithmuscode im Benutzerbereich ausführen, mit Unterstützung für containerisierte Bereitstellung und OTA-Fernaufrüstung. Kurz gesagt: Die SPS ist eine „speicherprogrammierbare Steuerung", die IPC-Lösung ein „programmierbarer Industriecomputer" – erstere realisiert Steuerung, letztere die Verschmelzung von Steuerung, Berechnung und Erweiterbarkeit.
F: Was ist das POD-Reduktionsmodell und warum ist es für den digitalen Zwilling so wichtig?
A: POD (Proper Orthogonal Decomposition, eigentliche orthogonale Zerlegung) ist eine datengetriebene Modellreduktionsmethode. Durch Singulärwertzerlegung umfangreicher vorab berechneter Daten werden die wenigen „Basismoden" mit dem höchsten Energieanteil extrahiert, wodurch eine hochdimensionale FEA-Berechnung, die ursprünglich Minuten dauerte, auf eine niedrigdimensionale Interpolationsrechnung von wenigen Dutzend Millisekunden komprimiert wird. Für den digitalen Zwilling wäre eine Echtzeit-Spannungsfeldberechnung ohne POD-Reduktion eine unlösbare Aufgabe – denn das Bedienpersonal kann nicht 3–5 Minuten auf ein FEA-Ergebnis warten. Keludes Lösung rekonstruiert mit 15 Basismoden 99,2 % der Information aus 1.000 Betriebsbedingungen, bei einer Online-Berechnungszeit von nur 15–30 ms.
F: Wie verarbeitet Keludes Datenplattform die massiven Gerätedaten?
A: Es kommt eine dreistufige Architektur zum Einsatz. Edge-Ebene (KruEdge-Gateway): Jedes Gerät speichert lokal 30 Tage Volldaten (ca. 45–150 GB); bei Netzwerkunterbrechung wird automatisch zwischengespeichert und nach Wiederherstellung übertragen. Speicherebene: Basierend auf der TimescaleDB-Zeitreihendatenbank verarbeitet ein einzelner Knoten 240.000 Zeilenschreibvorgänge pro Sekunde; Rohdaten werden nach 90 Tagen automatisch auf Minuten- und Stundenwerte heruntergesampelt. Serviceebene: Das KruGateway-API-Gateway stellt den einheitlichen Ausgang nach außen bereit und unterstützt die vier Protokolle OPC UA, MQTT, HTTP REST und gRPC, mit durchschnittlich 2,8 Millionen API-Aufrufen pro Tag und einer 95-Perzentil-Antwortzeit unter 15 ms. Die Berechtigungsverwaltung erfolgt dreidimensional nach „Gerät + Daten + Funktion", um die Datensicherheit in Multi-Tenant-Szenarien zu gewährleisten.
F: Ist diese Eigenentwicklung für alle Kunden geeignet?
A: Derzeit richtet sie sich vor allem an Kunden und Anwendungsszenarien mit hohen Anforderungen an Intelligenz, wie etwa in der Metallurgie, im Hafen oder in der Kernkraft – Branchen, die Fernbedienung, Gerätezustandsmanagement oder schlanke Instandhaltung benötigen. Für allgemeine Szenarien, die nur grundlegende Anschlagfunktionen erfordern, bietet Kelude weiterhin eine Standardproduktlinie auf Basis ausgereifter SPS-Lösungen an. Eigenentwicklung und Standardlösung laufen parallel – erstere setzt auf Differenzierung und baut technologische Barrieren auf, letztere deckt den preissensiblen Basismarkt ab. Beide Ansätze schließen sich nicht gegenseitig aus, sondern sind eine gestaffelte Produktstrategie für unterschiedliche Kundengruppen.