Kelude In-House Control System & Digital Twin

In the crane manufacturing industry, control systems and digital platforms are increasingly becoming the dividing line that determines product competitiveness. While most manufacturers still rely on generic PLCs paired with third-party HMIs as their "standard" approach, Kelude has chosen a fundamentally different technology path—from the underlying hardware to the upper-level algorithms, from data acquisition to Digital Twin, everything is developed in-house. This isn't about making the supplier list look better; it's because generic solutions hit an inherent performance ceiling when faced with the complex operating conditions of cranes.

This article breaks down the technical logic behind Kelude's in-house approach across three layers: the integrated hardware-software architecture of the control system, the modeling and prediction capabilities of the Digital Twin platform, and the integration scheme of the data platform. Each layer is benchmarked against generic solutions in terms of cost, performance, and scalability.

In-House Control System: IPC + Real-Time Linux + Proprietary Algorithms Replace Generic PLCs

Digital Twin Platform: Unity 3D + WebGL, POD Reduced-Order Models, LSTM Prediction

Kelude's Digital Twin platform isn't built to "show off 3D visuals"—its core value lies in three things: seeing clearly, calculating accurately, and predicting early. The platform's underlying logic can be summarized as a closed-loop chain: "data → model → inference → decision."

Visualization Layer: WebGL interaction powered by Unity 3D. Kelude chose Unity 3D as its 3D rendering engine and compiles the scenes to WebGL format, allowing users to access the full 3D digital model of the crane through a browser without installing any client software. This model is far more than a static CAD display—it maps all equipment motion states in real time: crane bridge travel position, trolley position, lifting height, and load sway angle are all pushed from the data platform to the front end via WebSocket, with a refresh rate of 20fps (50ms resolution) and visual latency under 100ms. When an operator opens a browser in the ground control room, they see the exact same 3D scene as what's visible from the operator cabin.

To ensure fast loading of the 3D scene in the browser, the R&D team implemented a series of performance optimizations: the model's polygon count was reduced from 8 million faces in the original CAD to 150,000 faces (preserving all external features while removing invisible internal details), textures use the KTX2 compression format to reduce GPU memory usage, the animation controller uses a state machine pattern rather than frame-by-frame animation, and first-frame loading is kept under 4 seconds (on a 100Mbps network).

Physics Inference Layer: POD reduced-order models solve the real-time simulation challenge. The biggest technical hurdle for Digital Twin isn't "looking realistic"—it's "computing fast enough." A typical finite element model of a 100-ton Bridge Crane main girder can have over 300,000 degrees of freedom. Solving a single static load case with commercial FEA software (such as ANSYS or Abaqus) takes 3–5 minutes—which is completely unacceptable for real-time inference.

Kelude's solution is a POD reduced-order model (Proper Orthogonal Decomposition). The core idea is straightforward: the stress distribution of a structure under the vast majority of operating conditions can be approximated by a linear combination of a small number of "basis modes." The R&D team pre-computed the full-field stress response for 1,000 representative operating conditions (combinations of different load positions, load magnitudes, and trolley positions) using ANSYS, then applied Singular Value Decomposition (SVD) to extract the top 15 basis modes with the highest energy contribution. These 15 modes account for 99.2% of the cumulative energy, meaning that 15 basis functions can reconstruct the vast majority of information from all 1,000 conditions.

During online operation, the system only needs to perform interpolation and linear combination in the 15-dimensional low-dimensional space based on the current measured load conditions. A single stress field calculation is compressed to 15–30ms, with precision loss controlled within 5%. This means the Digital Twin system can follow every lifting operation of the crane and refresh the full stress field heatmap of the main girder in real time—operators no longer see isolated strain gauge readings on screen, but a panoramic view of "where the stress is, where the fatigue is" across the entire girder.

Field deployment data: On three 100-ton Bridge Cranes, each unit is equipped with 16 fiber-optic strain sensors (FBG) and 4 accelerometers, with a data acquisition frequency of 1Hz. The POD model completes a full stress field inference every second and overlays the results onto the Unity 3D model. The system has been running continuously and stably for over 14 months (as of June 2026), completing more than 37 million inference cycles without a single instance of model divergence or abnormal calculation results.

Prediction Layer: LSTM time-series models enable remaining useful life prediction. The advanced capability of Digital Twin isn't just "understanding the present"—it's "anticipating the future." Building on the stress field data output from the POD reduced-order model, Kelude has integrated a fatigue life prediction module based on LSTM (Long Short-Term Memory) networks.

The LSTM model's input features include: real-time maximum equivalent stress of the main girder from POD inference, stress cycle count (extracted via rainflow counting), mean and amplitude distribution of the load spectrum, cumulative equipment operating time, and ambient temperature. The output is: remaining fatigue life of critical main girder zones (expressed in cycle counts) and an early warning level (four levels: green / yellow / orange / red). The model uses a sliding window input of 720 time steps (corresponding to 12 hours of historical data) to predict fatigue accumulation over the next 7 days.

Training data source: Before deployment, the R&D team trained the LSTM model offline using 12 months of historical operating data from three prototype units (containing 1.2 million valid samples). Once in live operation, the model automatically performs incremental updates every 24 hours, incorporating newly generated data into the training set to adapt to equipment aging trends and changing operating conditions. In validation runs from October 2025 to June 2026, the model achieved a Mean Absolute Percentage Error (MAPE) of 8.3% for 7-day predictions of main girder fatigue accumulation versus measured values. The prediction lead time is sufficient to support maintenance teams in scheduling inspections before unplanned downtime occurs.

Additionally, the platform integrates vibration prediction modules for the hoisting mechanism's gearbox and motor bearing. By extracting time-frequency domain features from acceleration signals (FFT + envelope spectrum) and feeding them into LSTM models, the system can provide 7–14 days of advance warning for bearing inner ring / outer ring faults. Across the 8 deployed units, the model has issued 47 warnings in total, of which 43 were confirmed as genuine faults during on-site shutdown inspections—an accuracy rate of 91.5%, with an average lead time of 11.3 days.

Data Platform: OPC UA/MQTT Acquisition, Time-Series Database, API Gateway

The control system generates data, and the Digital Twin consumes it—the bridge between the two is the data platform. Kelude's data platform architecture follows a three-layer design of "edge acquisition → aggregation → storage → service output," with clear technology selection logic at each layer.

Edge Acquisition Layer: OPC UA as the primary protocol, MQTT as a supplement. At the device level, Kelude's in-house "KruEdge" edge acquisition gateway runs on the industrial PC inside the control cabinet and communicates with the KruControl runtime via the OPC UA protocol. The choice of OPC UA is deliberate: it natively supports data modeling (transmitting "semantic" data rather than raw values—for example, "main girder max equivalent stress / MPa / sensor point FBG-03"), security encryption (X.509 certificate mutual authentication + AES-256 transport encryption), and automatic backfill of historical data when connections are interrupted. The gateway collects three categories of data: equipment status variables (speed, current, torque, and position for the hoisting, crane bridge, and trolley mechanisms), safety variables (overload sensor, limit switch, and brake status), and structural health variables (FBG strain, acceleration, temperature)—approximately 600 data points in total, with a configurable acquisition frequency of 1–100Hz.

For legacy equipment that doesn't support OPC UA (such as models older than 3 years, some of which use Modbus RTU Protocol), the edge gateway bridges the gap via a Modbus-to-OPC UA protocol adapter module. Additionally, for a small amount of telemetry data with lower real-time requirements (such as GPS position, ambient temperature/humidity, and energy consumption statistics), the MQTT protocol is used to report at 5-minute intervals, reducing the data load on the control layer.

Storage Layer: Hybrid storage architecture based on a time-series database. With 600 data points continuously collected at 1–100Hz, a single device generates approximately 1.5–5GB of data per day (depending on acquisition density). If 50% of Kelude's in-service equipment (approximately 200 units) were fully connected to the data platform, annual data write volume would reach 100–360TB. Traditional relational databases clearly cannot handle this write load.

Kelude's storage solution is a two-tier hybrid architecture: The first tier is local caching—each device's edge gateway is equipped with a 256GB NVMe SSD that caches the most recent 30 days of full-resolution data (approximately 45–150GB per unit). Data is not lost during network interruptions and is automatically backfilled once connectivity is restored. The second tier is a cloud-based time-series database—using the open-source TimescaleDB (a PostgreSQL-based time-series extension) deployed on private servers, with a wide-table schema designed around "device ID + timestamp + sensor point ID" and a time partition granularity of 72 hours. Measured write performance: a single node (8 cores, 32GB) can sustain 240,000 rows per second, with 95th percentile query latency under 50ms (for full-data queries of a single device over a 30-day range).

To address the cost of historical data storage, the team also designed data compression and aggregation policies: raw data is retained for 90 days (for fault tracing and model training); data from 90 days to 1 year is downsampled to one record per minute (aggregated as average + maximum + minimum); data older than 1 year is downsampled to one record per hour. The total storage footprint of the full dataset plus the two downsampled tiers is only 12%–15% of the original raw data volume.

Service Layer: Unified API gateway. Once data is stored, who consumes it? The Digital Twin front end needs real-time status data, the web portal needs historical trend curves, the mobile terminal app needs alert push notifications, and third-party systems (such as a customer's MES or ERP) need API integration—each consumer has different data formats, transport protocols, and permission requirements. Kelude developed its in-house "KruGateway" API gateway to address this challenge.

KruGateway is built on top of the open-source Kong gateway, with custom extensions tailored for industrial scenarios. It provides unified access for four protocols—OPC UA, MQTT, HTTP REST, and gRPC—and normalizes all incoming data into standard JSON before routing it to downstream consumers. Access control at the gateway layer operates along three axes: device scope, data scope, and function scope. For example, a customer may be restricted to viewing only the 10 devices assigned to them (device scope), may read status data but not modify control parameters (function scope), and may be blocked from seeing safety sensor data within that status feed (data scope). The gateway also includes built-in data flow throttling and cache acceleration. For high-frequency requests from Digital Twin frontends (refreshing at 20 fps), the gateway automatically caches the most recent 3 seconds of snapshot data, so every frontend render doesn't have to hit the database.

As of June 2026, KruGateway handles an average of approximately 2.8 million API calls per day, with a 95th-percentile Response time under 15 ms and a monthly availability rate of 99.97%.

Self-Built vs. Off-the-Shelf: Cost, Performance, and Scalability Compared

The three technical breakdowns above explain the underlying logic of Kelude's self-developed solution. But the final decision on technology selection isn't made by the R&D team—it's made by management, and they care about one core question: what does this self-built approach actually deliver over a generic solution, and is the extra investment in time and resources justified?

The table below provides a quantitative comparison across three dimensions: cost, performance, and scalability.

From the comparison above, a clear logic emerges: the ceiling of a general-purpose PLC solution isn't a matter of cost—it's a matter of architecture. Its processing power, real-time performance, openness, and scalability confine it to the realm of "programmable logic control," unable to support higher-order capabilities like intelligent algorithms, Digital Twins, and industrial big data analytics. Kelude's IPC + real-time Linux approach essentially repositions a high-performance industrial PC into the role of a Controller—trading surplus computing power for development flexibility and future expansion headroom.

Of course, this approach comes with its own trade-offs. The biggest one is R&D investment—from project initiation in 2021 to mass production deployment in 2024, the KruControl platform has accumulated over 32 million CNY (approx. $4.7 million) in development costs, with more than 120 person-years of engineering effort. For a mid-sized manufacturing company with annual revenue in the hundreds of millions, this is a figure that stands out on the balance sheet. The second trade-off is supply chain management—procuring components for IPC industrial PCs, the custom motherboard lead time (averaging 12–16 weeks), and the adaptation and validation of the real-time Linux kernel are all far more complex than buying an off-the-shelf PLC.

But Kelude's management is clear-eyed about this technology path: at the inflection point where the crane industry shifts from "scale competition" to "technology competition," the "good enough" of general-purpose PLCs is becoming "not good enough." Rather than wait for competitors to capture the high-end market with their own self-developed solutions, it's better to spend three years building the technology moat first.

Beyond the Crane: A Technology-First Strategy

Returning to the title of this article: it's about more than just building cranes. Kelude Heavy Industry has been manufacturing cranes for two decades, but what truly sets this company apart from its peers isn't the tonnage it can handle or the complexity of orders it can take—it's what happens in the "invisible places" inside the crane: every line of code in the control system, every basis function in the Digital Twin, and every data pipeline in the data platform—all built in-house.

General-purpose PLC solutions are certainly mature and reliable, but the boundaries they define are the performance ceiling of the crane. Kelude chose to break through that ceiling with an IPC + real-time Linux architecture, to turn Digital Twin from a demonstration tool into an engineering tool using POD reduced-order models, and to transform equipment data into enterprise assets with a self-developed data platform. Together, these three pillars form the technology foundation of Kelude Heavy Industry in the Smart Crane space.

This path hasn't been fast—from kickoff in 2021 to mass production in 2024, it took over three years. And it hasn't been cheap—32 million CNY (approx. $4.7 million) in R&D investment is no small sum for a manufacturing company. But the Kelude team shares one conviction: a technology moat is the only asset that price wars can't erode. What general-purpose PLC solutions can't do, Kelude's self-developed approach can—and that's the source of differentiation.

FAQ

Q: What is the fundamental difference between Kelude's self-developed IPC + real-time Linux control system and a general-purpose PLC?
A: The fundamental difference lies in system architecture openness and computing power ceiling. A general-purpose PLC's software and hardware are closed-defined by the vendor; users can only program within the vendor's framework (e.g., ladder diagram, SCL language) and cannot run self-developed advanced algorithms. Computing power is also limited by low-power ARM processors. Kelude's IPC solution uses Intel x86 processors, delivering 8–10 times the computing power of high-end PLCs. It runs a PREEMPT_RT real-time Linux kernel, allowing arbitrary C++/Python algorithm code to run in user space, with support for containerized deployment and OTA remote upgrades. In short, a PLC is a "programmable logic controller," while the IPC solution is a "programmable industrial computer"—the former achieves control; the latter achieves the convergence of control + computing + expansion.

Q: What is the POD reduced-order model, and why is it so important for Digital Twin?
A: POD (Proper Orthogonal Decomposition) is a data-driven model reduction method. It performs singular value decomposition on a large set of pre-computed data to extract the few "basis modes" that capture the highest energy share, compressing a high-dimensional FEA solve that would take minutes into a low-dimensional interpolation computation that completes in tens of milliseconds. For Digital Twin, without POD reduction, real-time stress field inference would be an impossible task—operators can't wait 3–5 minutes for an FEA solve to finish before seeing results. Kelude's solution reconstructs 99.2% of the information from 1,000 operating conditions using just 15 basis modes, with online computation time of only 15–30 ms.

Q: How does Kelude's data platform handle massive volumes of equipment data?
A: It uses a three-tier architecture. Edge layer (KruEdge gateway): each device caches 30 days of full-resolution data locally (approximately 45–150 GB), with automatic caching during network interruptions and backfill upon reconnection. Storage layer: built on the TimescaleDB time-series database, a single node handles 240,000 rows of writes per second; raw data is retained for 90 days, then automatically downsampled to minute-level and hour-level granularity. Service layer: the KruGateway API gateway provides unified external output, supporting four protocols—OPC UA, MQTT, HTTP REST, and gRPC—handling an average of 2.8 million API calls per day with 95th percentile response times under 15 ms. Access control is enforced across three dimensions—"device + data + function"—ensuring data security in multi-tenant scenarios.

Q: Is this self-developed solution suitable for all customers?
A: Currently, it targets customers and application scenarios with high intelligence requirements, such as metallurgy, Port, and nuclear power industries that need remote operation, equipment health management, or lean maintenance. For general-purpose scenarios that only require basic Hoisting functionality, Kelude continues to offer a standard product line based on mature PLC solutions. The self-developed and general-purpose approaches run in parallel—the former builds differentiation and technology barriers, while the latter covers cost-sensitive base markets. The two paths are not mutually exclusive; they represent a tiered product strategy serving different customer segments.