Next Article in Journal
Seismic Data Enhancement for Tunnel Advanced Prediction Based on TSISTA-Net
Previous Article in Journal
Wavelet-Enhanced Transformer for Adaptive Multi-Period Time Series Forecasting
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Applied Sciences
Volume 15
Issue 23
10.3390/app152312699
applsci-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Communication

Industrial Metaverse and Technical Diagnosis of Electric Drive Systems

by
Natalia Koteleva
1,
Nikolay Korolev
2,* and
Margarita Kovalchuk
3
1
Department of Automation of Technological Processes and Production, Empress Catherine II Saint Petersburg Mining University, 2, 21 Line of Vasilyevsky Island, 199106 St. Petersburg, Russia
2
Department of Applied Competencies in Digital Technologies, Empress Catherine II Saint Petersburg Mining University, 2, 21 Line of Vasilyevsky Island, 199106 St. Petersburg, Russia
3
Department of Electrical Power Engineering and Electromechanics, Empress Catherine II Saint Petersburg Mining University, 2, 21 Line of Vasilyevsky Island, 199106 St. Petersburg, Russia
*
Author to whom correspondence should be addressed.
Appl. Sci. 2025, 15(23), 12699; https://doi.org/10.3390/app152312699
Submission received: 24 October 2025 / Revised: 14 November 2025 / Accepted: 28 November 2025 / Published: 30 November 2025
Browse Figures
Review Reports Versions Notes

Abstract

This article presents a part of the industrial metaverse for electric drive system diagnostics. The advantages of using a low-code/no-code platform for electric drive systems diagnostics are demonstrated. Five diagnostic scenarios were developed, programmed, and implemented. The article demonstrates the implementation and use of the platform’s main functional blocks: a visualization block (which displays the state of electric machines in any user-friendly form—graphs, Park’s vector diagrams, or diagnostic curves); a digital twin block (which simulates various engine states); a digital twin block with an engine defect (which simulates faulty engine states); and an artificial intelligence block (which trains classification model to predict various engine states). Experiments on training the artificial intelligence block using a misalignment defect dataset are presented. The dataset was divided into six classes: engine operation with/without a defect under no load, engine operation with/without a defect under a 50% load, and engine operation with/without a defect under a 100% load. The workflow for training and using the model, the basic training approaches, and the distinguishability of the presented classes are demonstrated. The model training results are shown. The article presents a methodology for extensive testing of program functionality. The obtained results demonstrate the feasibility of implementing a low-code/no-code platform and the feasibility of solving the assigned tasks with its help, as well as the simplification and reduction in engineering solution development time.

1. Introduction

Electric machines are a part of any industrial enterprise. A large number of scientific works are dedicated to increasing the efficiency of electric machines [1,2] and technical diagnosis of electric drive systems [3,4]. There are two types of induction motor faults: mechanical and electrical. For example, defects of rotor and stator—mechanical faults, open-phase and circuit faults—are electrical faults [5,6]. Four steps make up the beginning of the process of fault detection: 1. Locating the fault. 2. Identifying the faulty elements. 3. Understanding the reasons for incipient failure. 4. Forecasting the pattern of faults [7]. There are several hardware and software solutions applied in diagnostic systems for electric drives [8,9]. As a rule, all these solutions have a number of limitations; they allow diagnosis of only certain defects. For example, article [10] describes the influence of motor rotor bending on vibration characteristics of an electric drive system. Article [11] conducts open-circuit fault diagnosis in a voltage source inverter. The main problem for diagnostic systems is the lack of data that accurately links defects and their causes. There are a number of fundamental studies describing the acquisition of such data [12]. For example, article [13] presents a vibration, current, torque, and RPM dataset for multiple fault conditions in industrial-scale electric motors under randomized speed and load variations. However, complete, comprehensive information on all types of defects is still a problem [14]. Under conditions of such uncertainty, artificial intelligence systems are often the main devices used in diagnostic systems [15,16]. For example, reference [17] uses an adapted YOLO model, and ref. [17,18] uses the graph neural networks method. However, their implementation and application in real production systems should occur along with a change in the general concept of diagnosing defects in electrical machines. Small companies and large corporations not only have gaps in the scale of production, but also, of course, they have gaps in material, technical, and organizational resources [19,20]. A good tool for reducing this gap is the concept of the metaverse, or, in particular, the industrial metaverse [21,22]. The industrial metaverse is a concept that includes three main components—the real environment, the virtual environment, and the environment of interaction between the real and virtual space [23,24]. The industrial metaverse is the concept of Industry 5.0 [25,26]. The main paradigms of Industry 5.0 are being human-centric, sustainable, and resilient, and achieving flexibility, customization, and human–machine collaboration, etc. [27,28]. Each considerable direction of development in Industry 5.0 did not arise out of nowhere. They were added on to and developed the Industry 4.0 concept [27,29]. Should new technologies be implemented according to the Industry 5.0 concept if the ideology of Industry 4.0 technology cannot be seen everywhere, and digital transformation is sometimes much slower than initially expected? It should be emphasized that the ideology of the Industry 5.0 concept does not cancel the ideology of the Industry 4.0 concept, but only adjusts and supplements it in light of reality [30,31]. Industrial enterprises do not always keep pace with the rapid development of new technologies. Often, the effect of their implementation is significantly lower than the production risks. A situation arises in which enterprises, on the one hand, are forced to improve their competitiveness and implement new technologies, for example, by introducing new measurement methods and tools [32,33] or machine vision systems [34,35], and implementing new principles of digital transformation management [36,37]. On the other hand, the costs of employee training, installation, and other expenditures force a wait-and-see approach when implementing new technologies [38,39]. To a large extent, all of the above applies to small companies and enterprises [40]. Thus, the strategy of waiting for complete-package solutions, including new technologies and easily implemented solutions based on the plug-and-produce principle, has led to the need to develop solutions that allow for immediate impact, literally upon first connection [41,42]. This has resulted in the appearance of low-code/no-code platforms and systems [43,44]. These are mainly used at the level of CRM systems in business analytics [45,46]. The use of low-code/no-code platforms and systems at the level of technological processes, on the one hand, cannot be called widespread, while on the other hand, it cannot be said that such an approach is a complete innovation. It is enough to recall PLCs that are not programmable but configurable via a WEB interface [47,48]. Essentially, such PLCs reduce development time, can be quickly implemented in some technological areas, and are easily reconfigured if necessary. However, full-featured low-code/no-code platforms for some tasks—for example, for the task of diagnosis of electric drive systems—are not widespread. This is undoubtedly due primarily to the lack of standardization of existing equipment-diagnostic approaches. This paper presents an approach to creating low-code/no-code platforms for electrical equipment diagnostics and the concept of an industrial metaverse. The emergence of such platforms at every level of the industrial metaverse architecture will help solve various problems not only in the development but also in the operation of industrial equipment. The goal (hypothesis) of this work is to develop technical solutions for creating an industrial metaverse for the technical diagnosis of electric drive systems.
This article consists of several parts. Section 2, Materials and Methods section describes the industrial metaverse architecture and the functional blocks of the low-code/no-code platform. Section 3, Experiments, provides a technical description of the laboratory unit, the data acquisition process, and a list of main scenarios. Section 4 visualizes each scenario available for execution on the low-code/no-code platform and provides a discussion. Section 5 contains conclusions on the results obtained and further applications of the low-code/no-code platform.

2. Materials and Methods

The process of building an industrial metaverse cannot be accomplished by simultaneously affecting all enterprise areas. The authors propose a range of industrial enterprise areas where concept of an industrial metaverse is most appropriate to develop. Electrical equipment diagnostics plays a significant role for a number of reasons. Electrical equipment itself is present in all small and large industrial facilities, and diagnostic methods are so diverse that they can be applied to any facility at minimal volumes, and their scaling will not significantly alter the overall infrastructure. Generally speaking, the industrial metaverse for electrical equipment diagnostics includes physical, cyber–physical, and social spaces, as well as interaction layers between them [23]. A flowchart of this interaction is presented in Figure 1. Physical space is a combination of real-world objects. In this work a laboratory unit functions as the real-world object. Its detailed description is presented in Section 3, Experiments.
Since the industrial metaverse is based on existing solutions, the principles of interaction between physical and cyber–physical space are somewhat understood. For example, the concept of a digital twin and its use both as a standalone tool and as part of a diagnostic system (e.g., for life cycle assessment) is a more well-developed area. However, the generation of diagnostic scenarios and the generation of a service engineer avatar (essentially a digital twin of the service engineer) are less well-developed. A low-code/no-code platform can be used for any type of interaction and any layer of the industrial metaverse’s architecture. However, its goal is to improve human–machine interaction, which means it aims to shorten the connection between physical and social space.
The goal of this work is to create a low-code/no-code platform for electrical equipment diagnostics. As the project is experimental, the platform’s functionality is minimal. However, the resulting platform must be consistent with the concept of the industrial metaverse.
The diagnostic platform operates in two modes: configuration and real-time. In configuration mode, platform functional blocks are combined using drag-and-drop on the configuration field, establishing connections and interdependencies. Table 1 presents the platform’s functions and their application features. Freely available icons from https://icon-icons.com were used to represent functions in the software.

3. Experiments

The laboratory unit for conducting experiments is shown in Figure 2. It contains two asynchronous motors (load and test), current and voltage sensors, a frequency converter, a data acquisition device, and a PLC.
The technical parameters of the laboratory asynchronous motors are as follows: power (W)—1500; voltage source (V)—380; rotor speed (rpm)—1390; number of pole pairs—2; moment of inertia (J, kg*m2)—0.0034; power factor—0.79; efficiency factor—0.9; torque capacity—2.3; starting torque ratio—2.3; and starting current ratio—6.2.
A misalignment defect was simulated in a laboratory experiment. One of the platforms supporting the motors was raised, causing the shafts of the two motors to be misaligned. Raising was achieved by turning the screw one thread. The difference to simulate the defect was 2.3 mm. The appearance of the laboratory unit before and after the defect simulation are shown in Figure 3a,b.
Five scenarios were developed to test the system’s functionality. Scenario 1: Reading, writing, and visualizing real data from electrical equipment. Scenario 2: Generating synthetic data with an engine digital twin. Scenario 3 Generating synthetic data including defect data with an engine digital twin. Scenario 4: Training the AI block to classify real defects and engine states. Scenario 5: Using the AI block to determine the defect and engine state in real time. To implement each scenario, functional blocks were connected in the configuration field and launched for execution.
The goal of this study was to evaluate the ability of human–machine interaction (HMI) using a low-code/no-code platform to recognize defects using visual tools and an AI-powered defect recognition unit. The developed scenarios were run several times. The data obtained during the experiments are available in the repository—https://github.com/nkot06/metaverseDrive2025 (accessed on 10 November 2025). Additionally, the software application can be tested using a large number of people. To ensure the integrity of the experiment, they can be divided into three groups: people who do not possess electrical drive servicing skills but possess programmer skills; people who possess programmer skills but do not possess electrical drive servicing skills; and people who possess neither programmer nor electrical drive servicing skills. When conducting such experiments, it is recommended to use the NASA-TSL questionnaire [50,51]. It is recommended to have participants fill out this questionnaire immediately after running the scenario. Otherwise, you may receive distorted feedback. It is recommended to use the questionnaire in electronic form. In this case, the users are asked to evaluate constructs by moving a slider scaled from 0 to 100 in increments of 1. It is better if the scale itself is not visible, and only its minimum and maximum are shown. This will allow for a more accurate assessment. All responses should be recorded in the database and processed by the system.

4. Results and Discussion

Figure 4 shows the flowchart for implementing Scenario 1: reading, writing, and visualizing real data from electrical equipment.
The scenario required connecting a real engine to the system and configuring real-time parameter recording to the database, as well as visualization in the system in three formats: a graph, a Park vector, and a diagnostic curve. Enabling and disabling various visualization types had to be tested. Furthermore, the connection and visualization had to be configured via augmented-reality glasses. It should be noted that the connection via augmented-reality glasses was tested only in the first scenario. This option could have been used in other scenarios but was not used. Disabling and enabling various visualization types was also performed only in the first scenario; all were subsequently enabled.
Figure 5, Figure 6 and Figure 7 show the real-time data obtained in the scenario.
Figure 7 shows the diagnostic curve. This curve is obtained by the mathematical transformations described in our previous study [49]. The figure shows two curves. They are practically indistinguishable from each other. This means the engine is operating in a normal state. As soon as the diagnostic curve begins to deviate from the normal state curve, this deviation is classified as a defect.
Figure 8 shows the diagram for implementing Scenario 2. A MATLAB model was launched in real time as a digital twin of the engine, to which parameters were transmitted through the system to configure the state of the engine used in the model and record the obtained data in the database. To execute this scenario, we used a Matlab 2024 model developed in a previous study and described in [49]. Connecting the model to the low-code/no-code platform was accomplished via the Matlab RESTful API. A request to the model was initialized via JSON, and the response was processed, also in JSON format.
Figure 9, Figure 10 and Figure 11 show images of the model data generated by the program.
Figure 12 shows a diagram for implementing Scenario 3: generating synthetic data including defect data with an engine digital twin. Defects were generated using a MATLAB model. Three types of defects were generated: a stator short circuit (interturn phase A), another stator short circuit (interphase AB), and rotor bar breakage.
Figure 13, Figure 14 and Figure 15 show images of the data obtained for an engine with a defect in the program.
Figure 16 shows the diagram for implementing Scenario 4: training the AI block to classify real defects and engine states
This scenario involves several operating modes, with switching possible between manual and automatic modes. The first mode involves data labeling. This can be performed in both automatic and manual modes. In automatic mode, the engine automatically identifies the states it believes should be assigned to a new class. This mode can only be tested by accumulating large sets of training data. This mode was not available in our experiment. In the second mode, data is assigned to a specific class. The system is then turned off, the next state is simulated, the next class is assigned, and so on. During the experiments, states comparable to six classes were simulated. They are listed and described in Table 2.
Figure 17, Figure 18 and Figure 19 show the data collected by the system after processing. It was impossible to obtain these graphs immediately in the system’s current form, as data visualization occurs for each class separately. The graphs are presented in this form to demonstrate the spread of data used in the classification algorithms.
As can be seen, the data obtained for tuning the classification algorithms is easily distinguishable. This is performed to simplify module setup and demonstrate its capabilities. Furthermore, the experiments are repeatable and can be easily reproduced, allowing for the algorithm’s correct operation to be verified in real time. Before launching the algorithm, it was trained on 78 training datasets. Thus, 13 datasets were captured for each class, 4 of which were in the test set and 9 in the training set.
In our previous study [36], we demonstrated that the most convenient, fast, and accurate method for constructing an AI model for classifying defects is one in which a family of diagnostic curves obtained in each experiment is fed to the model’s input. Since the platform is low-code, a classifier was selected from available libraries that did not require significant configuration. The Aeon Classification Rocket Classifier model was used for training. The number of kernels for the Rocket transform was chosen to be 2000. The accuracy score was the quality assessment metric. Since the classes are clearly distinguishable, the model’s accuracy was expected to be 1. The model trained quickly and produced good results (accuracy score = 1) because the data was clearly distinguishable. This is confirmed by Figure 17, Figure 18 and Figure 19. The confusion matrices for the training and test datasets are shown in Figure 20 and Figure 21.
During the system’s operation, people were required to accumulate enough data in training mode to train the classifier for each class, wait for it to train, and when the model’s state changed from learning to done, save the model for loading and testing in the next scenario.
Figure 22 shows the diagram for the implementation of Scenario 5: using the AI block to determine the defect and engine state in real time.
In this scenario, a trained model is loaded into the AI model block. Various engine states are simulated in real time. These states are displayed to the user as informational messages. The messages correspond to the class descriptions given in Table 1.
Each of the scenarios presented in the paper was run and tested 27 times. Each run resulted in error-free execution, fully supporting the functionality described in Table 1 for each platform block.
The scientific novelty of this research is the development of a functional and organizational framework for a low-code/no-code platform for the rapid deployment of industrial metaverses in solving the problems of diagnosing the condition of electrical machines, suitable for small and large industrial enterprises.

5. Conclusions

This article explores the development of a low-code/no-code platform as a component of an industrial metaverse for electric motor diagnostics. The platform’s functionality was evaluated on a laboratory unit, with preliminary results indicating its potential effectiveness for known diagnostic methods. However, these findings represent an initial step; scaling the system and improving diagnostic accuracy requires a more profound integration of the underlying physical processes. Key challenges include the nuanced nature of engine defects and the difficulty of their precise classification. The proposed approach offers a practical pathway for incremental adoption. Enterprises can deploy the platform with existing diagnostic methodologies, later expanding its capabilities by incorporating advanced techniques such as alternative machine learning algorithms, automatic state clustering, or AutoML. Further development must also address the accuracy of digital twins, as simulated defects currently lack full correspondence to real-world failures. A critical success factor for a unified industrial metaverse will be the establishment of standardized, clear representations of processes and assets across both virtual and real spaces. Addressing these challenges is a vital research direction. Continued investigation will be essential to mature the industrial metaverse concept and enable industrial enterprises to progress toward the full realization of Industry 5.0.

6. Patents

Certificate of state registration program for computers No. 2023614972 Russian Federation. Program for monitoring diagnostic data of asynchronous electric drive by current and voltage/N.A. Korolev, A.V. Boykov; applicant and copyright holder “Empress Catherine II Saint Petersburg Mining University”.—No. 2023613721; declared 2 March 2023; published 9 March 2023.—1.
Certificate of state registration program for computers No. 2024616314 Russian Federation. Program for identifying diagnostic characteristics of AC electric drives in real time/N.A. Korolev, N.I. Koteleva; applicant and copyright holder “Empress Catherine II Saint Petersburg Mining University”.—No. 2024614818; declared 12 March 2024; published 12 March 2024.—1.

Author Contributions

Conceptualization, N.K. (Natalia Koteleva) and N.K. (Nikolay Korolev); methodology, N.K. (Natalia Koteleva); software, N.K. (Natalia Koteleva); validation, M.K. and N.K. (Nikolay Korolev); formal analysis, N.K. (Natalia Koteleva), M.K. and N.K. (Nikolay Korolev); investigation, N.K. (Natalia Koteleva) and N.K. (Nikolay Korolev); resources, N.K. (Natalia Koteleva), M.K. and N.K. (Nikolay Korolev); data curation, N.K. (Natalia Koteleva); writing—original draft preparation, N.K. (Natalia Koteleva); writing—review and editing, M.K. and N.K. (Nikolay Korolev); visualization, N.K. (Natalia Koteleva); supervision, N.K. (Natalia Koteleva); project administration, N.K. (Natalia Koteleva); funding acquisition, N.K. (Natalia Koteleva) and N.K. (Nikolay Korolev). All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Informed Consent Statement

Not applicable.

Data Availability Statement

The data obtained during the experiment are available in the repository—https://github.com/nkot06/metaverseDrive2025 (accessed on 10 November 2025).

Conflicts of Interest

The authors declare no conflicts of interest.

References

  1. Yurievich, V.B.; Nguyen, T.H. Stochastic Pulse-Width Modulation and Modification of Direct Torque Control Based on a Three-Level Neutral-Point Clamped Inverter. Energies 2024, 23, 6017. [Google Scholar] [CrossRef]
  2. Mohammed, H.S.; Sabry, A.H.; Hameed, H.K.; Uğurenver, A. Impact of pulse-width modulation techniques on inverter efficiency and motor current quality in permanent-magnet synchronous motor drives: A simulation study. Measurement 2025, 258, 119107. [Google Scholar] [CrossRef]
  3. Skamyin, A.N. Method for determining the harmonic contribution of consumer installations based on the application of passive filters. IET Gener. Transm. Distrib. 2024, 18, 2464–2479. [Google Scholar] [CrossRef]
  4. Zhukovskiy, Y.L.; Buldysko, A.D.; Revin, I.I. Induction Motor Bearing Fault Diagnosis Based on Singular Value Decomposition of the Stator Current. Energies 2023, 16, 3303. [Google Scholar] [CrossRef]
  5. Nandakumar, S.; Gunasekaran, S. Investigating inter-turn insulation fault detection and classification in adjustable motor drives using novel hybrid machine learning approach. Ain Shams Eng. J. 2025, 16, 103556. [Google Scholar] [CrossRef]
  6. Al Smadi, T.; Gaeid, K.S.; Mahmood, A.T.; Hussein, R.J.; Al-Husban, Y. State space modeling and control of power plant electrical faults with neural networks for diagnosis. Results Eng. 2025, 25, 104582. [Google Scholar] [CrossRef]
  7. Glowacz, A. Thermographic fault diagnosis of electrical faults of commutator and induction motors. Eng. Appl. Artif. Intell. 2023, 121, 105962. [Google Scholar] [CrossRef]
  8. Maulik, S.; Konar, P.; Chattopadhyay, P. Strategic fusion of horizontal frame vibration with stator current for improved fault diagnosis of variable frequency drive. Measurement 2025, 258, 119322. [Google Scholar] [CrossRef]
  9. Wang, J.; Zhao, Y.; Han, L.; Shen, Y.; Yuan, W. Application of Fast High-Order Symmetric Difference Analytic Energy Spectrum Kurtosis for Wind Power Drive Chain Fault Localization. Digit. Signal Process. 2025, 169, 105708. [Google Scholar] [CrossRef]
  10. Huang, F.; Chen, C.; Wang, Z.; Wang, T.; Yang, M. Influence of motor rotor bending on vibration characteristics of electric drive system. Mech. Syst. Signal Process. 2025, 236, 113009. [Google Scholar] [CrossRef]
  11. Yan, H.; Peng, Y.; Shang, W.; Kong, D. Open-circuit fault diagnosis in voltage source inverter for motor drive by using deep neural network. Eng. Appl. Artif. Intell. 2023, 120, 105866. [Google Scholar] [CrossRef]
  12. Bacha, A.; El Idrissi, R.; Janati Idrissi, K.; Lmai, F. Comprehensive dataset for fault detection and diagnosis in inverter-driven permanent magnet synchronous motor systems. Data Brief 2025, 58, 111286. [Google Scholar] [CrossRef]
  13. Jung, W.; Kim, J.; Jang, K.; Yun, S.-H.; Lim, D.; Jin, M.; Park, Y.-H. Vibration, current, torque, RPM dataset for multiple fault conditions in industrial-scale electric motors under randomized speed and load variations. Data Brief 2025, 62, 111954. [Google Scholar] [CrossRef]
  14. Pengbo, Z.; Renxiang, C.; Xiangyang, X.; Lixia, Y.; Mengyu, R. Recent progress and prospective evaluation of fault diagnosis strategies for electrified drive powertrains: A comprehensive review. Measurement 2023, 222, 113711. [Google Scholar] [CrossRef]
  15. Ertargin, M.; Orhan, A.; Yildirim, O.; Gurgenc, T. Automated fault classification of asynchronous motor using mobile phone accelerometer Parallel Residual, CNN-GRU. Measurement 2025, 253, 117539. [Google Scholar] [CrossRef]
  16. Yüksek, G. Fault detection and classification in synchronous motors with a novel optimized CNN-GRU framework. Electr. Power Syst. Res. 2026, 252, 112430. [Google Scholar] [CrossRef]
  17. Qi, R.; Zhao, T.; Wei, B.; Peng, B.; Chen, Z.; Wang, X. Mechanical fault diagnosis of on-load tap changers using time–frequency vibration analysis and a lightweight YOLO model. Measurement 2025, 256, 118441. [Google Scholar] [CrossRef]
  18. Wang, B.; Wang, M.; Xu, Y.; Wang, L.; Chen, S.; Chen, X. A diagnosis method based on graph neural networks embedded with multirelationships of intrinsic mode functions for multiple mechanical faults. Def. Technol. 2025, 50, 364–373. [Google Scholar] [CrossRef]
  19. Zhukovskii, Y.L.; Suslikov, P.K. Identification and classification of electrical loads in mining enterprises based on signal decomposition methods. J. Min. Inst. 2025, 275, 5–17. [Google Scholar]
  20. Meier, A.; Eller, R.; Peters, M. Creating competitiveness in incumbent small- and medium-sized enterprises: A revised perspective on digital transformation. J. Bus. Res. 2025, 186, 115028. [Google Scholar] [CrossRef]
  21. Shahzad, F.; Zhang, Q. Leveraging the metaverse ecosystem: How institutional factors, adoption of metaverse-related technologies, and absorptive capacity drive performance in high-tech small and medium-sized enterprises. Inf. Manag. 2025, 62, 104080. [Google Scholar] [CrossRef]
  22. Zheng, J.; Zhang, J.Z.; Au, K.M.; Storey, V.C.; Wang, H.; Yang, Y. Shaping innovation pathways: Metaverse application configurations in high-technology small- and medium-sized enterprises. Decis. Support Syst. 2024, 187, 114336. [Google Scholar] [CrossRef]
  23. Guo, J.; Leng, J.; Zhao, J.L.; Zhou, X.; Yuan, Y.; Lu, Y.; Mourtzis, D.; Qi, Q.; Huang, S.; Song, X.; et al. Industrial metaverse towards Industry 5.0: Connotation, architecture, enablers, and challenges. J. Manuf. Syst. 2024, 76, 25–42. [Google Scholar] [CrossRef]
  24. Lyu, Z.; Fridenfalk, M. Digital twins for building industrial metaverse. J. Adv. Res. 2024, 66, 31–38. [Google Scholar] [CrossRef]
  25. Martínez-Gutiérrez, A.; Díez-González, J.; Perez, H.; Araújo, M. Towards industry 5.0 through metaverse. Robot. Comput.-Integr. Manuf. 2024, 89, 102764. [Google Scholar] [CrossRef]
  26. Henkel, D.A.; Ivens, B.S. Conceptualizing the Industrial Metaverse: From Technological Layers to Business Value. Ind. Mark. Manag. 2025, 131, 58–72. [Google Scholar] [CrossRef]
  27. Li, S.; Xie, H.-L.; Zheng, P.; Wang, L. Industrial Metaverse: A proactive human-robot collaboration perspective. J. Manuf. Syst. 2024, 76, 314–319. [Google Scholar] [CrossRef]
  28. Tanjung, T.; Ghazali, I.; Mahmood, W.H.W.; Herawan, S.G. Drivers and barriers to Industrial Revolution 5.0 readiness: A comprehensive review of key factors. Green Technol. Sustain. 2025, 3, 100217. [Google Scholar] [CrossRef]
  29. Piccarozzi, M.; Silvestri, C.; Fici, L.; Silvestri, L. Metaverse: A possible sustainability enabler in the transition from Industry 4.0 to 5.0. Procedia Comput. Sci. 2024, 232, 1839–1848. [Google Scholar] [CrossRef]
  30. Latino, M.E. A maturity model for assessing the implementation of Industry 5.0 in manufacturing SMEs: Learning from theory and practice. Technol. Forecast. Soc. Change 2025, 214, 124045. [Google Scholar] [CrossRef]
  31. Mourtzis, D.; Wang, L. 3-Industry 50: Perspectives concepts technologies. In Manufacturing from Industry 4.0 to Industry 5.0; Mourtzis, D., Ed.; Elsevier: Amsterdam, The Netherlands, 2024; pp. 63–96. [Google Scholar] [CrossRef]
  32. Khokhlov, S.; Abiev, Z.; Makkoev, V. The Choice of Optical Flame Detectors for Automatic Explosion Containment Systems Based on the Results of Explosion Radiation Analysis of Methane- and Dust-Air Mixtures. Appl. Sci. 2022, 12, 1515. [Google Scholar] [CrossRef]
  33. Kochneva, A.A.; Zaytseva, E.V.; Katuntsov, E.V. Reducing redundancy of laser scanning data for building digital terrain models. Model. Optim. Inf. Technol. 2023, 11. [Google Scholar] [CrossRef]
  34. Romashev, A.O.; Nikolaeva, N.V.; Gatiatullin, B.L. Adaptive approach formation using machine vision technology to determine the parameters of enrichment products deposition. J. Min. Inst. 2022, 256, 677–685. [Google Scholar] [CrossRef]
  35. Boykov, A.V.; Payor, V.A. Machine vision system for monitoring the process of levitation melting of non-ferrous metals. Tsvetnye Met. 2023, 4, 85–89. [Google Scholar] [CrossRef]
  36. Deryabin, S.A.; Temkin, I.O. Ontological modeling and management of digital transformation of mining enterprises architecture. J. Min. Inst. 2025, 275, 130–144. [Google Scholar]
  37. Litvinenko, V.S. Digital Economy as a Factor in the Technological Development of the Mineral Sector. Nat. Resour. Res. 2020, 29, 3413. [Google Scholar] [CrossRef]
  38. Salminen, K.; Aromaa, S. Industrial metaverse–company perspectives. Procedia Comput. Sci. 2024, 232, 2108–2116. [Google Scholar] [CrossRef]
  39. Sergei, V. Khokhlov Application of digital simulation methods for predicting parameters of blasted rock muckpile. J. Min. Inst. 2025, 275, 196–204. [Google Scholar]
  40. Cho, Y.; Park, J.; Yoo, J.; Kim, S.; Park, H. A study on Gen-AI technology development trends to enhance small-medium sized enterprise digital competence and management quality. J. Entrep. Emerg. Econ. 2025, 17, 1193–1218. [Google Scholar] [CrossRef]
  41. Enamorado-Díaz, E.; García-García, J.A.; Escalona-Cuaresma, M.J.; Lizcano-Casas, D. Metaverse Applications: Challenges, Limitations and Opportunities-A Systematic Literature Review. Inf. Softw. Technol. 2025, 182, 107701. [Google Scholar] [CrossRef]
  42. Torayev, A.; Martínez-Arellano, G.; Chaplin, J.C.; Sanderson, D.; Ratchev, S. Towards Modular and Plug-and-Produce Manufacturing Apps. Procedia CIRP 2022, 107, 1257–1262. [Google Scholar] [CrossRef]
  43. Koprov, P.; Starly, B. Industrial metaverse meets IIoT: Low-code platforms for machine-to-machine and human-to-machine integration. Manuf. Lett. 2025, 44, 1254–1265. [Google Scholar] [CrossRef]
  44. Bradley, R.; Salim, S.S.; Anthony, B.W. Learning through development of a digital manufacturing system in a learning factory using low-code/no-code platforms. Manuf. Lett. 2025, 46, 10–15. [Google Scholar] [CrossRef]
  45. Sá, D.; Guimarães, T.; Abelha, A.; Santos, M.F. Low Code Approach for Business Analytics. Procedia Comput. Sci. 2024, 231, 421–426. [Google Scholar] [CrossRef]
  46. Nour Eldin, A.; Baudot, J.; Dalmas, B.; Gaaloul, W. Low-code solutions for business process dataflows: From modeling to execution. Inf. Syst. 2025, 135, 102577. [Google Scholar] [CrossRef]
  47. Schäfer, M.; Moll, P.; Brocke, L.; Coutandin, S.; Fleischer, J. Model for Web-Application based Configuration of Modular Production Plants with automated PLC Line Control Code Generation. Procedia CIRP 2019, 83, 292–297. [Google Scholar] [CrossRef]
  48. Mellado, J.; Núñez, F. Design of an IoT-PLC: A containerized programmable logical controller for the industry 4.0. J. Ind. Inf. Integr. 2022, 25, 100250. [Google Scholar] [CrossRef]
  49. Koteleva, N.; Korolev, N. A Diagnostic Curve for Online Fault Detection in AC Drives. Energies 2024, 17, 1234. [Google Scholar] [CrossRef]
  50. Hart, S.G.; Staveland, L.E. Development of NASA-TLX(Task Load Index): Results of Empirical Theoretical Research. In Advances in Psychology; Hancock, P.A., Meshkati, N., Eds.; North-Holland: Amsterdam, The Netherlands, 1988; pp. 139–183. [Google Scholar] [CrossRef]
  51. Babaei, E.; Dingler, T.; Tag, B.; Velloso, E. Should we use the NASA-TLX in HCI? A review of theoretical and methodological issues around Mental Workload Measurement. Int. J. Hum.-Comput. Stud. 2025, 201, 103515. [Google Scholar] [CrossRef]
Applsci 15 12699 g001
Figure 1. Industrial metaverse architecture for electromechanical equipment diagnostics.
Figure 1. Industrial metaverse architecture for electromechanical equipment diagnostics.
Applsci 15 12699 g001
Applsci 15 12699 g002
Figure 2. The laboratory unit.
Figure 2. The laboratory unit.
Applsci 15 12699 g002
Applsci 15 12699 g003
Figure 3. (a) The laboratory unit without a misalignment defect. (b) The laboratory unit with a misalignment defect.
Figure 3. (a) The laboratory unit without a misalignment defect. (b) The laboratory unit with a misalignment defect.
Applsci 15 12699 g003
Applsci 15 12699 g004
Figure 4. Scenario 1: Reading, writing, and visualizing real data from electrical equipment.
Figure 4. Scenario 1: Reading, writing, and visualizing real data from electrical equipment.
Applsci 15 12699 g004
Applsci 15 12699 g005
Figure 5. Graph of real-time data obtained in the program in three modes.
Figure 5. Graph of real-time data obtained in the program in three modes.
Applsci 15 12699 g005
Applsci 15 12699 g006
Figure 6. Park vector of real-time data obtained in the program in three modes.
Figure 6. Park vector of real-time data obtained in the program in three modes.
Applsci 15 12699 g006
Applsci 15 12699 g007
Figure 7. Diagnostic curve of real-time data obtained in the program in three modes.
Figure 7. Diagnostic curve of real-time data obtained in the program in three modes.
Applsci 15 12699 g007
Applsci 15 12699 g008
Figure 8. Scenario 2: Generating synthetic data with an engine digital twin.
Figure 8. Scenario 2: Generating synthetic data with an engine digital twin.
Applsci 15 12699 g008
Applsci 15 12699 g009
Figure 9. Model data generated by the program as a graph.
Figure 9. Model data generated by the program as a graph.
Applsci 15 12699 g009
Applsci 15 12699 g010
Figure 10. Model data generated by the program as a Park vector.
Figure 10. Model data generated by the program as a Park vector.
Applsci 15 12699 g010
Applsci 15 12699 g011
Figure 11. Model data generated by the program as diagnostic curves (1—normal state curve; 2—real state curve).
Figure 11. Model data generated by the program as diagnostic curves (1—normal state curve; 2—real state curve).
Applsci 15 12699 g011
Applsci 15 12699 g012
Figure 12. Scenario 3: Generating synthetic data including defect data with an engine digital twin.
Figure 12. Scenario 3: Generating synthetic data including defect data with an engine digital twin.
Applsci 15 12699 g012
Applsci 15 12699 g013
Figure 13. Engine with a defect data obtained in the program as a graph.
Figure 13. Engine with a defect data obtained in the program as a graph.
Applsci 15 12699 g013
Applsci 15 12699 g014
Figure 14. Engine with a defect data obtained in the program as a Park vector.
Figure 14. Engine with a defect data obtained in the program as a Park vector.
Applsci 15 12699 g014
Applsci 15 12699 g015
Figure 15. Engine with a defect data obtained in the program as a diagnostic curve (1—normal state curve; 2—real state curve).
Figure 15. Engine with a defect data obtained in the program as a diagnostic curve (1—normal state curve; 2—real state curve).
Applsci 15 12699 g015
Applsci 15 12699 g016
Figure 16. Scenario 4: Training the AI block to classify real defects and engine states.
Figure 16. Scenario 4: Training the AI block to classify real defects and engine states.
Applsci 15 12699 g016
Applsci 15 12699 g017
Figure 17. Input data for model training as a graph.
Figure 17. Input data for model training as a graph.
Applsci 15 12699 g017
Applsci 15 12699 g018
Figure 18. Input data for model training as a Park vector.
Figure 18. Input data for model training as a Park vector.
Applsci 15 12699 g018
Applsci 15 12699 g019
Figure 19. Input data for model training as diagnostic curves.
Figure 19. Input data for model training as diagnostic curves.
Applsci 15 12699 g019
Applsci 15 12699 g020
Figure 20. Confusion matrix for training data.
Figure 20. Confusion matrix for training data.
Applsci 15 12699 g020
Applsci 15 12699 g021
Figure 21. Confusion matrix for test data.
Figure 21. Confusion matrix for test data.
Applsci 15 12699 g021
Applsci 15 12699 g022
Figure 22. Scenario 5: Using the AI block to determine the defect and engine state in real time.
Figure 22. Scenario 5: Using the AI block to determine the defect and engine state in real time.
Applsci 15 12699 g022
Table 1. Low-code/no-code platform functions.
Table 1. Low-code/no-code platform functions.
NoFunction
Design		Function NameFeatures of ApplicationDescription
1Applsci 15 12699 i001EngineEngine technical data:
P—power, kW;
Uн—supply voltage, V;
n—rated speed, rpm;
p—number of pole pairs;
J—moment of inertia, kg·m2
η—efficiency factor;
cosφ—power factor;
Km—overload capacity;
Kp—starting torque multiple;
Ki—starting current multiple.
Equivalent circuit parameters:
Ls—stator inductance, H;
Lr—rotor inductance, H;
Lm—mutual inductance, H;
Rs—stator resistance, Ω;
Rr—rotor resistance, Ω.		Represents user’s interaction with real engine; for correct operation, it is necessary to set technical parameters used for calculations and ensure operation of other connected functions
2Applsci 15 12699 i002Real data/real data recorderReading real data from equipment/writing real data (user setting—the name of table to write to the database; if the value is default, the table name is assigned by the system).Links real equipment and databases used in the system
3Applsci 15 12699 i003Digital twin/engine modelEngine Technical data:
P—power, kW;
Uн—supply voltage, V;
n—rated speed, rpm;
p—number of pole pairs;
J—moment of inertia, kg·m2
η—efficiency factor;
cosφ—power factor;
Km—overload capacity;
Kp—starting torque multiple;
Ki—starting current multiple.
Equivalent circuit parameters:
Ls—stator inductance, H;
Lr—rotor inductance, H;
Lm—mutual inductance, H;
Rs—stator resistance, Ω;
Rr—rotor resistance, Ω.		Provides interaction with the model used as a digital twin; allows user to configure digital twin and specify features and boundary conditions used in simulation
4Applsci 15 12699 i004Synthetic data/synthetic data recorderReading/writing data generated by a digital model (digital twin) (user setting—the name of table to write to the database; if the value is default, the table name is assigned by the system).Links synthesized objects and databases and separates real data from generated data
5Applsci 15 12699 i005Broadcasting system output to wearable devices (augmented-reality glasses)The user sets the device’s IP address, permissions, and settings related to the system’s information security.Allows the user to customize interaction method and connection parameters with wearable devices
6Applsci 15 12699 i006Visualization blockThe user sets the types of visual data representations and the period (number of display points). Three modes can be enabled: graph mode, Park vector, and diagnostic curve.Provides selection and setup methods for visualizing data from engine
7Applsci 15 12699 i007Graph visualizationThe user selects the phase for which data should be displayed. In reality, these are Ia, Ib, and Ic. Allows user to configure graphical visualization
8Applsci 15 12699 i008Diagnostic curve visualization [49]The user sets the frequency (number of points per period) and number of segments.Allows user to configure the diagnostic curve
9Applsci 15 12699 i009Park vector visualizationThe user sets the frequency (number of points per period).Allows user to configure Park vector visualization
10Applsci 15 12699 i010Type of defect simulated by the systemThe user sets the type of defect.
The configuration of defects depends on the capability of the digital model used as a digital twin.		Enables setup, configuration, and execution of specialized code simulating engine defect
11Applsci 15 12699 i011Custom program codeThe user sets their own code or uses template code. One of the templates is a data preprocessing code.Allows user to create any custom code and execute it
12Applsci 15 12699 i012Artificial intelligence block for training the modelThe user selects artificial intelligence models and algorithms for training the model and the necessary parameters for training.Allows user to setup, configure, and launch built-in artificial intelligence models or custom models
13Applsci 15 12699 i013Class name input block for manual data labelingThe user sets the class name.Enables user to enter class name values
14Applsci 15 12699 i014Class name input block for auto data labelingThe user sets the templates for automatic class specification.Provides ability to customize existing templates and create new templates
15Applsci 15 12699 i015AI model training blockThe user sets the learning target and key learning quality metrics.Allows user to choose model training methods, various tuning coefficients, and also to add custom training algorithms
16Applsci 15 12699 i016Block indicating that training process has been completedThis block is informational. The user does not configure it.Provides visualization of AI model’s training goal achievement
17Applsci 15 12699 i017Trained AI model connection blockThe user sets the path to the saved AI model trained in advance.Allows user to load pre-trained model
18Applsci 15 12699 i018Electric motor diagnostic status output blockThe user sets state–class data pairsProvides visualization of current engine state or engine defect if one is detected
Table 2. List and descriptions of the classes.
Table 2. List and descriptions of the classes.
Class NumberClass Description
1engine operation without defect under no load
2engine operation without defect under 50% load
3engine operation without defect under 100% load
4engine operation under no load with misalignment defect
5engine operation with misalignment defect under 50% load
6engine operation with misalignment defect under 100% load
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Koteleva, N.; Korolev, N.; Kovalchuk, M. Industrial Metaverse and Technical Diagnosis of Electric Drive Systems. Appl. Sci. 2025, 15, 12699. https://doi.org/10.3390/app152312699

AMA Style

Koteleva N, Korolev N, Kovalchuk M. Industrial Metaverse and Technical Diagnosis of Electric Drive Systems. Applied Sciences. 2025; 15(23):12699. https://doi.org/10.3390/app152312699

Chicago/Turabian Style

Koteleva, Natalia, Nikolay Korolev, and Margarita Kovalchuk. 2025. "Industrial Metaverse and Technical Diagnosis of Electric Drive Systems" Applied Sciences 15, no. 23: 12699. https://doi.org/10.3390/app152312699

APA Style

Koteleva, N., Korolev, N., & Kovalchuk, M. (2025). Industrial Metaverse and Technical Diagnosis of Electric Drive Systems. Applied Sciences, 15(23), 12699. https://doi.org/10.3390/app152312699

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop