Scene Equipment Saving and Loading Method for Digital Twin Workshop

Abstract

The digital twin workshop contains a vast quantity of heterogeneous data from multiple sources, such as the historical state of workshop equipment, which is essential for analyzing implicit problems and bottlenecks in manufacturing tasks. Nevertheless, the current unidirectional and irreversible time flow of the digital twin workshop makes it difficult to optimize workshop productivity using historical data. This paper proposes a scene equipment saving and loading method for the digital twin workshop to address this issue. The initial steps involve defining a workshop information model which represents multiple pieces of workshop equipment in the virtual space and the content of the data it covers. This model stores data for each object type on the workshop using distinct data structures; a workshop element data saving and loading method is proposed, which can save the historical scene equipment data of the digital twin workshop and load the saved data into the digital twin software; finally, a case study is conducted to determine the data compatibility, the saving and loading efficiency, and the system’s ability to save and load actual workshop scenes. The results demonstrate that this method can efficiently save and load scene equipment data on the workshop, enabling workshop administrators to identify problems and bottlenecks in historical manufacturing tasks and then take steps to increase workshop productivity.

1. Introduction

The digitalization and intelligence of manufacturing workshops are constantly improving, and many new technologies are being invoked in the manufacturing field to improve workshop efficiency. As a key technology to achieve intelligent manufacturing, digital twin (DT) is undergoing a period of rapid development [1]. It was also listed by Gartner as an emerging technology for 2025–2030 [2]. In the process of implementing DT technology on the ground, the information model plays a crucial role, and the rationality of the model directly affects the application effect of DT.

A DT workshop is defined as a high integration of a physical workshop, workshop data, workshop service software and a virtual workshop, which can realize virtual–real mapping and real-time control of a manufacturing asset. Hence, information integration and interconnection of a DT workshop is an important guarantee and foundation for eliminating information silos and realizing workshop digitization and networking [3]. The workshop information model is the product of the digital representation of the physical entities and manufacturing processes in the workshop, and it can abstract the logical hierarchy of the massive amounts of data contained in the workshop, helping to realize the information integration, interconnection, and intelligent control-related functions in the workshop. Previous studies investigated the commonalities of workshop data and constructed generic encapsulation models, resulting in an 84.2% reduction in the time taken to model digital twin objects [4]. In addition to this, related data modeling work has been carried out at the level of manufacturing tasks [5], individual equipment [6], and tools [7]. Modeling the data on the workshop and abstracting it into different categories based on the characteristics and commonalities of the data can reveal opportunities to optimize the management of the data and improve the efficiency of the manufacturing tasks in the workshop. However, modeling and analyzing a broader range of objects in the workshop is challenging, and at this stage, there are still many studies that focus only on individual equipment or components for DT modeling. In addition, most of the DT in the studies are non-retrogressive in the time dimension, which is an obstacle when it comes to analyzing the implicit problem of workshop history.

In this paper, we propose a scene equipment saving and loading method for the DT workshop. The saving task is the process of writing the object information data from the DT workshop system to the local disk as an archive file, while the loading task corresponds to the process of loading the data information contained within the archive to the workshop software. This method makes it possible to save historical data for workshop equipment objects locally and return to historical time nodes when analyzing workshop manufacturing bottlenecks. A 3D historical time state scene is provided to the workshop administrator, helping them analyze the manufacturing process from a more detailed perspective.

The rest of this paper is structured as follows: Section 2 presents a literature review on building information models and using data for production process optimization in the DT workshop; Section 3 defines the DT workshop information model using a five-layer framework, proposes a workshop scene equipment saving and loading model and presents the principles and details of the workshop information saving/loading process; Section 4 introduces the case study test objects, system configuration and test methodology; Section 5 presents the results and a discussion of the case study’s testing of data compatibility, saving and loading efficiency as well as virtual workshop scene saving and loading capability; finally, conclusions and future works are drawn in Section 6.

2. Related Work

DT has been a powerful driver for manufacturing due to its numerous advantages, such as real-time operation, high accuracy, traceability and high integration [8]. The DT concept was first introduced in 2003 [1] and was initially used in aerospace [9,10]. Nowadays, DT technology is flourishing at both the theoretical and application levels, especially in the field of manufacturing. Researchers have conducted experiments focused on manufacturing assets [11,12], factories [13,14,15], workers [16], etc., during DT application research [8]. At this stage, the introduction of new technology concepts such as artificial intelligence, the Internet of Things (IoT), big data and cloud computing has also provided new development opportunities for DT.

Multi-source heterogeneous data are increasingly valued by academics in the DT workshop, and the analysis of this information can lead to opportunities for quality enhancement and cost savings. For example, Wu et al. [17] used tags such as BLE and RFID to achieve the real-time collection of product location information, and used genetic algorithms to achieve scheduling function based on devices’ location information. In addition to this, many studies have conducted a posteriori analyses based on historical data [18]. For example, Subramaniyan et al. [19] used workshop equipment history log data for bottleneck detection. Specifically, machine learning algorithms are used to parse the production line multi-device history data to identify the equipment that affects workshop throughput. Tang et al. [20] used a deep learning theory Bayesian optimization algorithm to construct a fault classification model for hydraulic axial piston pumps to accurately accomplish intelligent fault diagnosis of hydraulic pumps. The multi-source data in the DT workshop are important for optimizing the manufacturing process. Thus, determining how to describe and model the multi-source heterogeneous data on the workshop in a unified way has become increasingly urgent.

Data are a valuable asset for smart manufacturing [21]. The collection and analysis of heterogeneous data from multiple sources in the DT workshop can lead to new opportunities for workshop intelligence. However, the data generated with regard to the workshop are large, in different formats and continuously generated [22]. This makes it challenging to manage workshop data. Therefore, it is necessary to abstract the equipment in the workshop into information [23] and use the workshop information model to describe the state attributes of each piece of equipment in the workshop and the relationships between the equipment. Botkina et al. [24] proposed a DT model of a tool, based on which tool standardization data can be collected automatically and the digital virtual model can be continuously adjusted. Leng et al. [25] developed an open architecture machine tool. A semantic data model was constructed to describe the digital model of the machine tool, which contains elements such as process types, static attributes and communication interfaces. In the above study, the focus was on individual equipment or components on the workshop, and the rest of the multi-source information on the workshop has yet to be modeled and analyzed.

Liu et al. [26] established a DT model for aerospace component machining, which pointed out that the twin model dynamically integrated with data is the core of the DT system, and elaborated that the DT model of a machining product should have salient features such as geometry (shape, dimensions, tolerances, etc.), physical properties and process records. Um et al. [27] developed a data model based on CPS objects in which information about metadata, properties, models and communication details of the specified objects were included. Zhou et al. [28] modeled a DT system for vehicle operations and maintenance that contains a storage device layer, an information and communication layer as well as several other layers. Urbina Coronado et al. [29] established a low-cost MES framework. Objects such as tools, machines, products and operators in the workshop were described using attribute and relational information; the data were transferred according to the MTConnect standard. Zheng et al. [30] introduced the CPS system architecture for DT establishment. It divided the DT architecture into four layers, i.e., the physical layer, the data extraction and integration layer, the cyberspace layer and the interaction layer. In the data extraction and integration layer, data packets from the physical system can be received, normalized into machine-readable form and finally passed to the network layer. Liu et al. [31] proposed a DT-driven machining quality traceability and dynamic control method. A Bayesian network model was used to analyze the influence weights of factors affecting machining quality, and this was used to build an information model for machining quality traceability. In the above study, a broader range of workshop objects were modeled and analyzed, such as a machining unit [26,31], workshop assembly lines [27] and workshop production lines [28,29,30]. However, at this stage, the digital simulation of workshop objects has a non-retrogressive character in the time dimension and there is currently no way to save and load the action states of workshop objects. This makes it challenging to analyze workshop manufacturing bottlenecks through historical data and equipment historical states. The information from the cited works is presented in

Table 1. Information from cited works.

Reference	Modeling Objects	Support Time Backtracking?
[24]	Cutting Tool	Negative
[25]	Machine tool	Negative
[26]	Machining unit	Negative
[27]	Workshop assembly lines	Negative
[28]	Workshop production lines	Negative
[29]	Workshop production lines	Negative
[30]	Workshop production lines	Negative
[31]	Machining unit	Negative

.

The above analysis of the literature reveals that there are still some research gaps at this stage:

• Some studies do not model workshop information comprehensively enough, focusing only on a single piece of equipment or a component of the equipment, resulting in multiple sources of workshop information not being fully utilized.
• The workshop software at the present stage still has the one-way characteristics of time passing and non-returnability and lacks an effective means to return the workshop history status.
• Previous studies have lacked an effective means of building a modular system for saving and loading data from multiple sources in the workshop.

The above points are important, as they clarify the logical relationship of the multi-source heterogeneous information on the workshop and reproduce the historical action state of the workshop, helping the workshop administrator find the implicit bottlenecks. This is the focus of this study and will be discussed further in the following sections.

3. Materials and Methods

3.1. Workshop Information and Saving/Loading Model Definition

There are various types of equipment in the DT workshop, such as machine tools, AGVs and warehouses, and it is necessary to design their representations separately for each equipment type. Saving the information of the scene equipment in the workshop is the precondition for loading. This procedure concerns data reading/writing between the workshop software, runtime memory and local disk. This section introduces the information model of various workshop elements, including the types of elements and the information contained in each element; it also proposes the model of workshop scene equipment saving and loading and describes the system’s composition and the connection between each module.

3.1.1. Workshop Element Information Model

The data from the DT service system control the presence and operation of the equipment in the virtual workshop. Each workshop element contains two types of information: a 3D model and attribute behavior information, among which the 3D model is the external expression of workshop elements in the virtual workshop. This allows the workshop administrator to review them in an intuitive form, while attribute behavior information is used to describe the status and behavior of workshop elements; for example, the machine tool possesses attribute information such as the machine code, manufacturer, etc., and behavior information such as the machining action and working status.

Figure 1 depicts the types of data contained in the various elements of the workshop. Based on the logical relations, the information about the workshop elements is divided into five levels from the inside out.

Layer 1: DT Object. DT Object is an abstract concept used to describe the overall integration of all objects in the workshop. Workshop assets that can be digitally represented and can directly affect physical objects may be considered DT Objects.

Layer 2: Workshop information base class. This is the base class of all objects contained in the workshop, and it contains three classes in total according to the type of workshop information: element class, viewer class and info class. It contains the basic functions, such as the ability to create and destroy the objects. The use of a unified abstract base class to manage the creation and destruction of objects, memory allocation and release can improve system performance and code reusability.

Layer 3: Workshop information-derived class. Derived from the workshop information base class, it further elaborates the information type for the workshop element and initially specifies six major types of information contained in the workshop: machine tool, storage, transport, saved archive, fixed viewer and roam viewer classes.

Layer 4: Workshop information-specific object. Due to the presence of numerous variations within the same major device category, they are abstracted into another layer. This is the most fine-grained shop equipment specific object, which can be defined based on the workshop information derived class and the actual workshop situation.

Layer 5: Workshop information detail object. The information contained in the workshop information-specific object, which is mostly defined in the form of structures or fields within the concrete object class, is used to store the state and properties of the object. Such hierarchical classification allows for better management of extensive device information within the workshop.

To elaborate on the relationships between the components of the workshop elemental information in more detail and with greater specificity, a formal description method is introduced to explain them. The symbols, meanings and schematic use cases for representing the relations between the components of the element information are presented in

Table 2. Schematic table of mathematical symbols and their use cases.

Symbol	Meaning	Use Case	Explanation
∈	belong to	Workshop equipment ∈ Workshop object	Workshop equipment belonging to workshop object
→	inheritance	Machine tool class → Element class	Machine tool class inherited from element class
>	instance	Lathe class > Machine tool class	Lathe class is an instance of machine tool class
: (parament)	property	Machine tool: (ID, Manufacturer)	Machine tools have properties, such as their ID and manufacturer

.

As shown in Formula (1), the DT Object refers to all of the objects in the workshop, from which it is further divided into three workshop information base classes:

$$\left\{\begin{array}{c}\mathrm{Element}\mathrm{class}\in \mathrm{DT}\mathrm{Object}\\ \mathrm{Viewer}\mathrm{class}\in \mathrm{DT}\mathrm{Object}\\ \mathrm{Info}\mathrm{class}\in \mathrm{DT}\mathrm{Object}\end{array}\right.$$

(1)

The second layer of the workshop information model is explained here. Element class is a real physical entity in the workshop, which is the most basic element used to build the virtual workshop; viewer class is an abstract type used to help the workshop administrator view the workshop scene in the DT system, including a fixed viewer and roam rover, which do not actually exist in the physical workshop; the info class is used to store the archive data on the workshop and contains the information presented to the workshop administrator at the viewport level. Each workshop information-specific object has different properties and behavioral information, which are described in detail below:

(1)

Elements class

Machine tool class: Machine tools are an important part of a workshop, which undertakes various machining and cutting tasks. There may be several types of machine tools in a workshop, such as a vertical machining center, a horizontal machining center, a lathe, a milling machine and a grinding machine. The information describing the machine elements in the virtual shop includes their machine code, manufacturer, working status, alarm information, etc. The relationship between the machine tool class and the element class can be expressed by Formula (2). In addition, the machine tool class can instantiate a variety of objects. Each instance object has a variety of member attributes, and this relationship can be expressed by Formula (3).

$$\mathrm{MachineTool}\mathrm{class}\to \mathrm{Element}\mathrm{class}$$

(2)

$$\left\{\begin{array}{c}\mathrm{Lathe}\text{: }\left(Machinecode,Workingstate,\text{ …}\right)\text{ > }\mathrm{MachineTool}\mathrm{class}\\ \mathrm{Machining}\mathrm{center}\text{: }(Machinecode,Workingstate,\text{ …})\text{ > }\mathrm{MachineTool}\mathrm{class}\\ \mathrm{Grinding}\mathrm{machine}\text{: }\left(Machinecode,Workingstate,\text{ …}\right)\text{ > }\mathrm{MachineTool}\mathrm{class}\\ \text{…}\end{array}\right.$$

(3)

Transport class: Transport machines (AGVs, forklifts, conveyors, etc.) are responsible for transferring workblanks and (semi-)finished products from the workshop to the target location. The information describing the transport machines in the virtual workshop includes their equipment code, location, transport status, alarm information, etc. The relationship between the transport class and the elements class can be expressed by Formula (4). Transport class can instantiate a variety of objects. Each instance object has a variety of member attributes, and this relationship can be expressed by Formula (5).

$$\mathrm{Transport}\mathrm{class}\to \mathrm{Element}\mathrm{class}$$

(4)

$$\left\{\begin{array}{c}\mathrm{AGV}\text{: }\left(Machinecode,Position,\text{ …}\right)\text{ > }\mathrm{Transport}\mathrm{class}\\ \mathrm{Forklift}\text{: }(Machinecode,Position,\text{ …})\text{ > }\mathrm{Transport}\mathrm{class}\\ \mathrm{Conveyor}\text{: }\left(Machinecode,Position,\text{ …}\right)\text{ > }\mathrm{Transport}\mathrm{class}\\ \text{…}\end{array}\right.$$

(5)

Storage class: Storage elements are responsible for storing raw materials, finished products, etc., in the workshop, including shelves and warehouses, etc. In the virtual workshop, the storage elements are described by information such as capacity, area and storage records. The relationship between the storage class and the element class can be represented by Formula (6). The storage class can instantiate a variety of objects. Each instance object has a variety of member attributes, and this relationship can be represented by Formula (7).

$$\mathrm{Storage}\mathrm{class}\to \mathrm{Element}\mathrm{class}$$

(6)

$$\left\{\begin{array}{c}\mathrm{Shelf}\text{: }\left(Capacity,Storedrecord,\text{ …}\right)\text{ > }\mathrm{Storage}\mathrm{class}\\ \mathrm{Warehouse}\text{: }(Capacity,Storedrecord,\text{ …})\text{ > }\mathrm{Storage}\mathrm{class}\\ \text{…}\end{array}\right.$$

(7)

(2)

Viewer class

Fixed viewer: Fixed viewer acts as a “fixed camera” in the virtual workshop; it is responsible for displaying the real-time images of the specified position and angle in the workshop software. It is worth mentioning that the “fixed viewer” proposed in this paper and the “roam viewer”, which will be described below, are not real devices that exist in the physical workshop, but viewers that exist in the workshop software to allow users to observe the real-time 3D graphical screen of the workshop. The fixed viewer’s screen position and perspective are generally unchangeable. The workshop-fixed viewer is used to monitor important points in the workshop, such as the warehouse, machine tool spindle, conveyor belt, etc. The relationship between the fixed viewer class and the viewer class can be represented by Formula (8). The fixed viewer class can instantiate a variety of objects. Each instance object has a variety of member attributes; the relationship can be expressed by Formula (9).

$$\mathrm{FixedViewer}\mathrm{class}\to \mathrm{Viewer}\mathrm{class}$$

(8)

$$\left\{\begin{array}{c}\mathrm{Fixed}\mathrm{viewer}\mathrm{A}\text{: }\left(Position,Viewingangle,\text{ …}\right)\text{ > }\mathrm{FixedViewer}\mathrm{class}\\ \mathrm{Fixed}\mathrm{viewer}\mathrm{B}\text{: }(Position,Viewingangle,\text{ …})\text{ > }\mathrm{FixedViewer}\mathrm{class}\\ \text{…}\end{array}\right.$$

(9)

Roam viewer: Unlike fixed rovers, the roam viewer can move freely and adjust its viewpoint. Similar to a person walking through the workshop, a roam viewer allows the workshop administrator to roam freely through the virtual workshop and view the status and actions of its elements in real time. A roam viewer object is described in the virtual workshop according to its position, rotation and viewing angle. The relationship between the roam viewer class and the viewer class can be represented by Formula (10). The roam viewer class can instantiate an object that has multiple member attributes, and this relationship can be represented by Formula (11).

$$\mathrm{RoamViewer}\mathrm{class}\to \mathrm{Viewer}\mathrm{class}$$

(10)

$$\mathrm{Roam}\mathrm{viewer}\text{: }\left(Position,Rotation,\text{ …}\right)\text{ > }\mathrm{RoamViewer}\mathrm{class}$$

(11)

(3)

Info class

Saved archive class: Used to record and display information about the saved archive in the software interface, including the archive name, timestamp, controller name and workshop name. When an archive is created, this type of information is collected and updated in the software viewport. The relationship between the saved archive class and the info class can be expressed by Formula (12). The saved archive class can instantiate multiple objects, each with multiple member properties, and the relationship can be represented by Formula (13).

$$\mathrm{SavedArchive}\mathrm{class}\to \mathrm{Info}\mathrm{class}$$

(12)

$$\left\{\begin{array}{c}\mathrm{Archive}\mathrm{A}\text{: }\left(Archivename,Timestamp,\text{ …}\right)\text{ > }\mathrm{SavedArchive}\mathrm{class}\\ \mathrm{Archive}\mathrm{B}\text{: }(Archivename,Timestamp,\text{ …})\text{ > }\mathrm{SavedArchive}\mathrm{class}\\ \text{…}\end{array}\right.$$

(13)

3.1.2. Workshop Scene Equipment Saving and Loading Model

For the massive amounts of data covered in the DT workshop, a workshop scene equipment saving and loading method is proposed. This method can save the historical scene equipment data of the DT workshop and load the saved data into the DT software when analyzing the implicit problems of the workshop, which helps the workshop administrator to identify the problems in historical manufacturing tasks. As shown in Figure 2, the method framework is divided into three layers: the data layer, the system layer and the viewport layer.

For the data contained in the element information model presented in Section 3.1.1, this process takes place in the “data layer” of the saving and loading model. The information saving and loading operation is the process of serializing, deserializing, reading and writing the data contained in the data layer.

(1)

Data layer

In the data layer, various data structures are defined to store different types of workshop information. The data layer is the cornerstone of the saving and loading system and contains almost all the scene equipment data in the workshop. It is described in detail below.

Slot information: This object contains a type of structural data that cover the basic information of the workshop-saving profile. When there is a saving or loading requirement, a saving information object is constructed and the data to be saved or loaded are assigned to the member properties of the object, which is then (de)serialized to complete the requirement.

Slot data: Slot data form an aggregated relationship with the above saved information object. This structure contains the name of the archive, a timestamp detailing when the archive was created, the name of the scene and the name of the user in the scene.

Object data: Object data contain information about the subcomponents contained in the workshop object. This structure is the basic unit of saving, and it has an aggregated relationship with various data units.

Object component data: These data are also of structure type and contain the name, transform and other data information of the subcomponents of the workshop object.

Controller data: The workshop controller is used to control the workshop roam viewer, which records the perspective pitch and rotation for real-time control of the roam viewer.

Viewer data: There are two types of workshop viewer data: location information and rotation information. The location information records the coordinate data of the viewer in the workshop, while the rotation information records the rotation status data of the workshop viewer. It is important to note that the view rotation data of the controller used to control the workshop viewer is not the same as the rotation data of the viewer itself.

Script data: Workshop scripts are used to specify operations or rules in the workshop at a macro level, usually as visual scripts based on a blueprint system. The script names and the script data will be saved or loaded.

Element data: Element data are used to carry scenes or equipment in the workshop. These data include the class information, name information, transform information and type information of all scenes and equipment.

(2)

System layer

The system layer provides functions for saving and loading, which can be considered as an intermediate link between the data layer and the viewport layer, enabling the operation of the data layer and the presentation of important information to the workshop administrator through the viewport layer. This is described in further detail below.

Workshop subsystem: The workshop subsystem class is responsible for managing workshop system instances, storing workshop states and data. It has initialization and deinitialization functions; the initialization function can create the workshop subsystem object, allocate memory for it and load the workshop configuration and archive data, while the deinitialization operation can remove the workshop subsystem object, release memory and clean up the workshop state data. In addition, this class contains the logical flow framework for saving and loading functions, through which the steps specified in the framework are completed with the cooperation of other classes to implement these functions.

Async task: This task is used to start a multi-thread async task and perform corresponding operations after the user issues a save/load instruction, which includes the function to create an asynchronous task.

Save and load interface: This interface receives the saving or loading instructions requested by the workshop subsystem class, and it has two dummy functions that are implemented by the saving/loading system. Introducing the interface can increase the flexibility of the whole system, making it easy to extend and simplifying the implementation of functions.

Save and Load System: This class implements the saving and loading interface and forwards the saving or loading task to the file helper class. It also retrieves the archive file path. By entering the specified archive name, it can retrieve the full archive save path, which facilitates read and write operations on the archive.

File Helper: The file helper has methods used to save byte files to computer disks or load saved files from disks to byte files. The implementation of the file helper class functionality depends on the file manager class.

File Manager: The file manager can create or open an archive file, in addition to its functions of creating a reader/writer, obtaining a timestamp, etc.

Archive system: The archive system has serialization and deserialization methods. With the help of serialization methods, objects in the runtime data can be serialized to memory to await subsequent operations such as compression and writing to local files.

Compress manager: The compress manager is used to compress the saved data to the storage space of the memory, which utilizes a data compression method; in this study, the Zlib compression method was used.

Decompress manager: The reloaded data are subjected to data decompression methods.

(3)

Viewport layer

The graphical interface helps the workshop administrator rapidly and intuitively save or load workshop data. The user interacts with the interface at the viewport layer to ensure the system layer executes the relevant code to achieve the intended function. This process is described in detail below:

User Interface Module: The user interface is the direct medium between the user and the system operations. It contains methods for adding the interface to the viewport, as well as declaring delegated events that are triggered by mouse clicks on buttons in the interface.

User-defined delegate: This delegate has a trigger event bound to it; for example, when the user clicks the saving button in the interface, it conveys the saving command to the system layer.

3.2. Workshop Scene Equipment Saving and Loading Method

The workshop scene equipment saving and loading method is implemented by the data layer, the system layer, and the viewport layer. This section introduces the fundamental procedure and specifics of the workshop scene equipment saving and loading method, and it describes the conversion, reading and writing processes that occur when the system layer operates with data at various stages and in different forms.

3.2.1. Scene Equipment Saving and Loading Method Workflow

While saving and loading the workshop information, it is divided into three stages: runtime data stage, memory data stage and the local disk data stage. Figure 3 contains the information saving and loading flowchart.

(1)

Runtime data stage

During the runtime data stage, information related to the archive is obtained. Firstly, the archive name entered by the user from the viewport layer (or the default name if not specified by the user) is obtained via the DT Object class, and the save directory is created using this name. Next, the archive information is obtained, including the archive name, timestamp, scene name and username; this information will be used by the viewport layer to present a basic overview of the archive.

(2)

Memory data stage

In the memory data stage, the main focus is to serialize the workshop information into temporary memory segments and compress the data. First, the information to be saved is serialized using the archive system class. Secondly, the serialized data in memory are compressed using the compress manager, and the compressed data are stored in a new memory segment in the form of a TArray using the Zlib method.

(3)

Local disk data stage

The memory segment’s binary data are stored locally on the computer to create an archive file during the local disk data stage. The save/load system is used to implement the saving virtual functions in the save/load interface, while the file helper class is used to handle the actual read and write operations for the file. On the local drive, the saved data are kept as a save file.

3.2.2. Scene Equipment Saving and Loading Method Implementation

Depending on the form of data existence, saving and loading is divided into three stages: obtaining or loading saved data, serializing or deserializing saved data and saving or loading archive files. These stages are described in detail below.

(1)

Obtaining or loading data

In the obtaining data stage, the main tasks are to specify the file name and path and assign the data to the temporary object; in the loading data stage, the DT workshop object is rebuilt in the service software, and the workshop state is reset. Figure 4 shows the flowchart for obtaining or loading data.

As shown in Figure 4a, after a workshop administrator gives a saving command, the system begins by obtaining the archive name specified by the administrator; if the archive name is not specified, the default name is used. If the archive file already exists, subsequent saving operations will overwrite the existing data in the file. Once the archive file has been created, the multi-threaded task begins. Using multi-threaded asynchronous operations, it can speed up processing and avoid thread blocking, thus improving the performance. Three objects are created to temporarily store saved information. The element object is used to temporarily store information related to the equipment, such as the equipment name, location information, subassembly information, etc. The viewer object is used to temporarily store data, such as viewer position and rotation information, and the info object is used to temporarily store information such as the file name, timestamp, username, etc. Assigning data to the above three kinds of staging objects can help to classify the scattered data into groups and facilitate the serialization of object data into the memory.

As shown in Figure 4b, the rebuild operation is performed on the DT workshop object when the saved data are loaded into the memory to be used by the workshop software. After the rebuild is complete, the workshop state is restored, mainly by restoring the workshop script data, initializing the state of each component, etc. Once the above operation has been successfully completed, a signal is broadcast to prompt other modules to destroy the object, free memory and perform other operations. If the operation fails, the error information is reported to the workshop software so that it can be addressed by the workshop administrator.

(2)

Serialization or deserialization of data

The temporary objects are processed using serialization and compression functions and subsequently stored in the memory as dynamic arrays; the dynamic arrays in the memory can be deserialized to temporary objects using deserialization and decompression functions. Figure 5 shows the flowchart for serialization or deserialization information.

As shown in Figure 5a, when serializing data, first use the pointer to the workshop staging object as the input parameter and determine the legality of the staging object indicated by the pointer to be used for saving operations, including verifying whether the pointer is empty, whether the object has been destroyed, whether the object supports serialization, etc. If the object can be legally used for serialization, it will be serialized into memory. The principle is to create an in-memory archive object that will be used to serialize data into memory. This archive proxy object will take on additional operations for serialization, such as compressing data. The serialization command is given by the archive agent and delegated to the in-memory archive object, which serializes the data in the staging object into a new data segment in memory, waiting for the compression operation. When the data are compressed, no changes are made to the original data in memory, but a new segment is opened in the memory to write the compressed data. The compress manager compresses the data, and the archive system assigns the compressed data contents to write to the newly opened memory segment.

As shown in Figure 5b, when deserializing data in the memory data stage, the dynamic array in the memory is first obtained as an input parameter, and the data contained in this array are decompressed. The decompressed data will exist in the newly opened memory space in the form of bytes. The data are deserialized to obtain a DT Object, which has the state properties prior to solidification. After the object has been created, the object pointer is used as the input data for the next stage.

(3)

Save or load archive files

When saving the archive file, the dynamic array is localized in the memory and the display information of the viewport layer is updated after success; when loading the archive file, the data of the archive file are written to the memory according to the specified path. Figure 6 shows the flowchart for saving or reloading archive files.

As shown in Figure 6a, when saving archive files, first, the compressed dynamic array in memory is localized. This operation is implemented through the file manager. Specifically, a writer object is created to write an array of bytes of the specified length in memory to a sav file of the specified path using the write function. After the local file is written successfully, a different step is performed depending on whether the operation is successful or not. If the file is written successfully, the multithreaded task is closed, and the saving information is broadcast through a multicast delegate, which is used to notify other objects that the saving operation has been completed and to perform related operations, such as destroying the staging information object and updating the viewport level information to display the file details, etc. If the file is written unsuccessfully, the multithreaded task is closed first, and then error messages are reported through the log.

As shown in Figure 6b, when loading the archive file, the specified sav file will be read using the local archive file path as the input parameter, and the read data will enter the system memory as a dynamic array and wait for the next stage of deserialization operation.

4. Case Study

4.1. Test Objects and System Configuration

Based on Unreal Engine, this paper develops DTWorks, a standalone development tool that uses Client/Server (C/S) architecture and functions as a standalone program. The workshop scene equipment loading and saving method suggested in this study are included as a useful module. Developers may rapidly create DT workshop models using the DTWorks software platform, manage the entire life cycle of workshop equipment and achieve real-time interaction between physical and virtual equipment.

First, we tested the DTWorks workshop platform’s capacity to save and load various data types to confirm the platform’s compatibility. Then, we compared the DTWorks platform’s efficiency with that of the browser/server (B/S)-based workshop platform to confirm the superiority of the DTWorks platform. Finally, we tested its ability to save or load a DT workshop scene.

Table 3. System configuration table for running DTWorks and B/S architecture servers.

Index	Parameter	Value
1	Operating system	Windows 10 professional, 21H2
2	Central processor	AMD Ryzen7 5700 G, 3.80 GHz
3	Graphics processor	NVIDIA GeForce RTX 3060 Ti
4	System memory	24 GB RAM
5	Platform toolset	Visual Studio 2022 Community
6	Rendering engine	Unreal Engine 5.0.3
7	Network configuration	200 M broad band

displays the system configuration used to run the DTWorks platform and the B/S server. The B/S architecture has high cross-platform compatibility, and another device is utilized as the client of the B/S architecture, while Python is used to implement the functions connected to the saving and loading of the B/S server.

Table 4. System configuration table for running B/S architecture clients.

Index	Parameter	Value
1	Operating system	MacOS ventura 13.2.1
2	Central processor	Apple M1
3	System memory	8 GB RAM
4	Platform toolset	PyCharm CE 2023.1.2
5	Network configuration	200 M broad band

displays the client’s system configuration.

4.2. Test Methods and Processes

4.2.1. Test for Saving and Loading Multiple Types of Data

The diversity of devices in the DT workshop necessitates the use of multiple data types to describe the devices’ states. As test content, the compatibility of the DTWorks platform was evaluated by saving and loading multiple categories of workshop data. Figure 7 depicts the test procedure for each data type.

• Create a scene element for testing in the DTWorks platform and assign it a specified data type as a member variable; this is carried out in the editing mode of the software. The editing mode does not truly run the workshop scene, but it can finish creating and configuring workshop scene elements.
• Enter the runtime mode of the DTWorks platform and assign initial values to the member variables, which will actually run the workshop scene. In runtime mode, the scene elements and workshop data interact and communicate according to the code logic and rules.
• The value of the data changes, and subsequently, the data-saving command is given to save the data at this point locally on the computer.
• The value of the data changes again and the saved archive is selected in step 3 for loading. Observe whether the data are correctly loaded to the value at the time of saving.
• Still making changes to these data and closing the DTWorks software, subsequently reopen the software and select the saved archive from step 3 for loading and observe whether these data are correctly reloaded to the value at the time of saving.
• Repeat steps 3, 4 and 5 and perform them 10 times.

4.2.2. Test for Saving and Loading Large Amount of Data

The data in the DT workshop are massive, multi-source and heterogeneous. Therefore, it is challenging to save and load the large volume of data in the workshop using the workshop software. This section is divided into different cases to compare the efficiency of saving and loading large volumes of data.

The DTWorks software platform proposed in this study is a platform based on Client/Server (C/S) architecture, which has a secure form of access, fast processing speed and facilitates the processing of large amounts of data. Another kind of DT workshop platform based on browser/server (B/S) architecture is widely used at this stage. Although it has certain advantages in terms of deployment speed and development ease, it relies on a strong and stable network foundation and lacks data security, data transmission speed and the comprehensiveness of function implementation.

First, we evaluate the efficiency of saving and loading fundamental data types. For both platforms, we determine the efficacy of saving and loading large volumes of various data types, including Boolean, byte, integer, float and string. Based on the team’s prior knowledge of how frequently each data type is used in the DT workshop, various data volumes ranging from 1000 to 1,000,000 were specified for the saving and loading efficiency comparisons. Secondly, saving and loading efficiency tests are conducted on typical composite data in the workshop, including bearing temperature information, bearing vibration information and machine tool abrasion information. The test data are obtained from the PHM2010 and PHM2012 [32] datasets. Among them are 1,000,000 pieces of bearing temperature information detailing the date (hour, minute and second), sensor number and temperature; 1,000,000 pieces of bearing vibration information detailing the date (hour, minute, second and microsecond), horizontal vibration signal and vertical vibration signal; 1,000,000 pieces of machine tool abrasion information detailing the X/Y/Z three-dimensional force, X/Y/Z three-dimensional vibration and acoustic emission root mean square (AE-RMS) data content.

Figure 8 depicts the testing technique for saving and loading efficiency using the DTWorks workshop software platform proposed in this study.

• Create several scene elements for testing in the DTWorks software platform and add a structure type member variable to them. This operation is carried out in the edit mode of the software.
• Enter the runtime mode of the DTWorks software platform and initialize the data content within each struct.
• Change the data content within the struct and provide a save/load instruction; then, record the timestamp of the moment.
• Record the timestamp again when the saving/loading operation is completed.
• Record the time interval between two timestamps as the time used for saving/loading operations.
• Repeat steps 3, 4, 5 and 6, and calculate the average of the saving/loading time as the final result.

The procedure for testing data saving and loading efficacy using a B/S-based DT platform is very similar to that of DTWorks, with the following exceptions: due to the B/S architecture’s features, the saved archive is downloaded after the data have been saved on the server side and uploaded before the data are reloaded on the server side; the time spent on these two operations is also recorded. The B/S architecture’s saving and loading functions are implemented in Python and endowed with a 200 Mbps broadband connection. Due to the uniqueness of the test dataset, it is important to note that the data content does not change during repeated testing of the saving and loading efficiency of typical composite data using both platform architectures.

4.2.3. Test for Saving and Loading a Virtual Workshop Scene

DTWorks was used to create a virtual workshop scene with which to evaluate the functionality of the saving and loading module. Figure 9 depicts the constructed discrete manufacturing workshop plan, which includes a pallet exchange flexible manufacturing system marked as (1), a (semi-)finished product storage area marked as (2), five CNC machining centers marked as (3), a blank storage area marked as (4), six gantry machines marked as (5) and three AGV logistics carts and their charging stations marked as (6).

Modules used to save and load workshop scenes are incorporated into DTWoks. As depicted in Figure 10, the saving and loading user interface is called out in Runtime mode. The archive name window (marked as 1) is used to name the workshop scenes to be saved; the archive operation panel (marked as 2) is used to save, load and delete the workshop scenes; and finally, the archive list (marked as 3) displays the saved archives, along with the workshop scene thumbnail, archive name, workshop name and the timestamp.

5. Results and Discussion

5.1. Data Compatibility

In the actual test, nine data types were considered, each of which could be used to characterize distinct workshop equipment states. For instance, Boolean data can be used to describe the machine’s switching status, byte data can be used to store the machine’s error codes, integer data can be used to keep track of the number of workblanks in the warehouse, etc. The conclusive test results are displayed in

Table 5. Multi-type data saving and loading test results.

Index	Data Type	Use Case Example	Save-Load Ability
1	Boolean	The on–off state of the machine tool	True
2	Byte	Fault code of the machine tool	True
3	Integer	Inventory of workblank in the warehouse	True
4	Float	Spindle speed of the machine tool	True
5	String	Alarm information of the equipment	True
6	Vector	Location of the machine tool	True
7	Rotator	Rotation angle of the AGV	True
8	Transform	The scaling factor of the equipment model	True
9	Struct	Complex machine tool state dataset	True

.

According to Table 5, each of the nine data types can be effectively saved and loaded after 10 rounds of testing with the workshop scene device saving and loading system proposed in this study. The test results indicate that the system is compatible with multiple data types and can save and load data from multiple workshop devices.

5.2. Data Saving and Loading Efficiency

The test results for basic data type saving and loading efficiency tests based on the DTWorks architecture are displayed in

Table 6. Test results for basic data type saving and loading efficiency tests based on DTWorks architecture.

Content	1	2	3	4	5	6	7	8	9	10	Average
Saving
Blank control	34	33	33	33	33	34	34	33	34	33	33.4
Boolean	33	34	33	33	34	33	34	34	33	34	33.5
Byte	42	33	33	34	33	34	33	42	32	33	34.9
Integer	92	100	100	93	91	91	91	102	92	101	95.3
Float	217	213	217	209	209	208	225	217	217	209	214.1
String	120	119	117	118	118	110	114	111	119	118	116.4
Loading
Blank control	28	26	22	23	21	23	21	22	22	23	23.1
Boolean	27	25	27	28	26	27	30	22	19	21	25.2
Byte	30	27	28	31	31	28	34	31	29	28	29.7
Integer	68	73	67	68	69	65	65	67	71	63	67.6
Float	80	79	77	76	82	73	82	78	81	86	79.4
String	47	48	44	44	44	48	45	48	46	44	45.8

Unit in the table: ms.

, whereas the test results for the B/S architecture are displayed in

Table 7. Test results of basic data type saving and loading efficiency test based on B/S architecture.

Content	1	2	3	4	5	6	7	8	9	10	Average
Saving
Boolean	2	2	2	2	2	2	2	2	2	2	2
Byte	3	3	3	3	3	3	3	2	2	3	2.8
Integer	499	500	507	524	498	501	509	501	497	509	504.5
Float	676	691	690	688	688	683	692	689	689	696	688.2
String	15	16	16	16	14	16	15	15	15	14	15.2
Downloading
Boolean	26	24	29	24	20	27	26	20	26	25	24.7
Byte	56	66	57	56	59	51	49	54	48	55	55.1
Integer	209	205	289	244	288	322	376	292	276	293	279.4
Float	296	199	253	239	230	210	243	284	323	368	264.5
String	173	143	156	127	140	133	140	141	155	140	144.8
Uploading
Boolean	1	1	1	1	2	1	1	1	1	1	1.1
Byte	28	25	29	29	24	26	23	23	23	28	25.8
Integer	213	174	193	177	203	198	205	231	196	215	200.5
Float	372	348	388	314	315	287	301	292	440	396	345.3
String	32	37	32	38	43	32	32	30	41	30	34.7
Loading
Boolean	3	9	5	7	5	7	7	3	7	8	6.1
Byte	15	16	5	6	4	3	6	5	4	7	7.1
Integer	57	60	59	60	62	60	59	60	64	60	60.1
Float	74	78	75	79	78	75	76	77	78	76	76.6
String	15	7	9	10	11	11	10	10	11	11	10.5

Unit in the table: ms.

.

The test results for the two architectures are summarized in

Table 8. Comparison results of the efficiency for saving and loading basic data type.

Architecture	Data Type	Data Volume	Saving	Loading	Downloading	Uploading
DTWorks	Boolean	1000	0.1	2.1	-	-
DTWorks	Byte	100,000	1.5	6.6	-	-
DTWorks	Integer	1,000,000	61.9	44.5	-	-
DTWorks	Float	1,000,000	180.7	56.3	-	-
DTWorks	String	100,000	83.0	22.7	-	-
B/S	Boolean	1000	2.0	6.1	24.7	1.1
B/S	Byte	100,000	2.8	7.1	55.1	25.8
B/S	Integer	1,000,000	504.5	60.1	279.4	200.5
B/S	Float	1,000,000	688.2	76.6	264.5	345.3
B/S	String	100,000	15.2	10.5	144.8	34.7

Unit in the table: ms.

, and a graph comparing their efficiencies is presented in Figure 11.

As shown in Figure 11, the DTWorks system proposed in this paper is more efficient than the B/S-based comparison group for varying volumes and types of data saving/loading operations. Not only is the B/S-based DT system marginally slower than DTWorks in terms of processing speed, but it also has variable upload and download times dependent on network quality, in addition to the inherent network communication delays of the B/S architecture. Overall, the test results indicate that using DTWorks can increase saving efficiency by 82.6% and loading efficiency by 74.0% for basic data types.

Table 9. Test results for typical composite data saving and loading efficiency tests based on DTWorks architecture.

Content	1	2	3	4	5	6	7	8	9	10	Average
Temperature
Saving	488	467	486	487	487	471	489	476	489	467	480.7
Loading	258	247	252	247	250	245	248	244	247	252	249.0
Vibration
Saving	629	607	605	616	608	632	617	604	606	615	613.9
Loading	250	270	250	262	256	256	266	260	259	259	258.8
Abrasion
Saving	1359	1358	1333	1336	1362	1345	1336	1338	1340	1339	1344.6
Loading	408	411	413	403	401	415	406	405	407	415	408.4

Unit in the table: ms.

displays the test results for typical composite data saving and loading efficiency tests based on the DTWorks architecture, while

Table 10. Test results for typical composite data saving and loading efficiency tests based on B/S architecture.

Content	1	2	3	4	5	6	7	8	9	10	Average
Temperature
Saving	1289	1321	1300	1311	1303	1303	1295	1310	1305	1309	1304.6
Downloading	567	740	769	753	800	593	794	850	892	618	737.6
Loading	412	420	405	398	405	399	421	430	409	399	409.8
Uploading	290	322	236	292	307	307	291	332	297	333	300.7
Vibration
Saving	1162	1139	1134	1135	1138	1129	1133	1137	1130	1130	1136.7
Downloading	1298	1317	1305	1530	1245	1007	917	1423	1109	1057	1220.8
Loading	397	406	411	412	424	410	417	412	404	401	409.4
Uploading	543	442	541	496	475	615	582	687	640	580	560.1
Abrasion
Saving	3024	3045	3038	3032	3055	3052	3035	3028	3029	3025	3036.3
Downloading	1261	1295	1171	1234	1651	1532	1655	1807	1823	1613	1504.2
Loading	464	467	475	471	464	470	452	462	459	485	466.9
Uploading	497	554	559	649	727	668	621	508	460	442	568.5

Unit in the table: ms.

displays the test results for tests utilizing the B/S architecture.

The test results for the two architectures are summarized in

Table 11. Comparison results of the efficiency for saving and loading typical composite data.

Architecture	Data Type	Data Volume	Saving	Loading	Downloading	Uploading
DTWorks	Temperature	1,000,000	480.7	249	-	-
DTWorks	Vibration	1,000,000	613.9	258.8	-	-
DTWorks	Abrasion	1,000,000	1344.6	408.4	-	-
B/S	Temperature	1,000,000	1304.6	409.8	737.6	300.7
B/S	Vibration	1,000,000	1136.7	409.4	1220.8	560.1
B/S	Abrasion	1,000,000	3036.3	466.9	1504.2	568.5

Unit in the table: ms.

, and a graph comparing their efficiencies is presented in Figure 12.

As shown in Figure 12, DTWorks continues to demonstrate greater efficiency when saving and loading typical workshop composite data. DTWorks can save millions of complex pieces of data in milliseconds, whereas B/S-based implementations can take seconds. Overall, test results indicate that using DTWorks can increase saving efficiency by 73.6% and loading efficiency by 66.3% for typical complex data types.

In conclusion, compared to the DT workshop system based on B/S architecture, the workshop information saving and loading system proposed in this study is more efficient at saving and loading large volumes of data, completing all saving and loading tasks in milliseconds. All operations are multithreaded activities that have no effect on the workshop service software’s main thread.

5.3. Virtual Workshop Scene Saving and Loading Capability

As depicted in Figure 13, the example workshop scenes were saved locally to the computer according to the saving and loading system proposed in this paper, and the sav archive file was successfully created; the archive file was successfully reloaded to the DTWorks workshop software system by this system, and the historical scene state of the workshop was successfully restored.

In summary, a typical discrete manufacturing workshop scene was constructed using the DTWorks software platform, and the proposed system successfully implemented the saving and loading of the example workshop scene by giving commands through the workshop equipment saving and loading user interface, which correctly displays the relevant information for the archive.

6. Conclusions and Future Works

In this paper, we propose a scene equipment saving and loading method for the digital twin workshop. The following work is included.

• We define the information model for workshops. The DT workshop’s multi-source information is integrated into a five-layer framework that specifies the hierarchy of workshop elements, the inheritance relationship and the information content. The workshop’s overall architectural planning of multi-source information can enable developers to manage data more clearly and increase control efficiency.
• The composition of the system for saving and loading workshop information is presented. It is abstracted into a data layer, a system layer and a viewport layer, and the functions of the classes within each layer as well as the inheritance and dependency relationships between classes are described. Object-oriented programming techniques based on object-oriented programming can increase the code’s reusability and optimize its performance.
• The workflow of the information saving and loading method for workshop information is introduced. The detailed process of workshop information saving and loading is explained in three dimensions of data flow existence, namely runtime data, memory data and local disk data.
• A case study demonstrates that the proposed saving and loading system is feasible. The results show that the proposed saving and loading system is compatible with a wide variety of workshop data types, outperforms the B/S architecture of the DT workshop system in terms of operational efficiency and can effectively implement the saving and loading of workshop scenes.

Applying the method proposed in this paper to a complex DT workshop scenario allows for the management of large amounts of data and enables the DT system to have a time-tracing capability through the scene equipment saving and loading method, allowing workshop administrators to explore hidden problems from a broader perspective. However, there are some shortcomings in this paper; for example, it fails to incorporate human workers into the workshop information model. Additionally, the suggested workshop scene saving and loading method is unable to reload the time-continuous historical state of equipment.

Future research will consider incorporating human factors into the workshop information model for more comprehensive modeling. Furthermore, we will continue to investigate the time-flow characteristics of workshop equipment actions, creating a continuous 3D replay of the equipment’s historical action state. This continuous 3D replay will allow workshop administrators to comprehend potential equipment issues in greater depth and optimize them more precisely.