A history traceable digital twin model construction method

Abstract

The application discloses a kind of history traceable digital twin model construction methods.The application is based on the modeling method of AutomationML behavior model, realize the conversion of digital twin model from state data model to action state model;By establishing double-end storage rules, realize with COLLADA standard state data and JSON standard action data with fixed time particle precision packing into history data package and storing in history database;By the analysis method of history data package, restore past time state data and action data and load into GUI interface and three-dimensional virtual model to trace back and replay.The application fills the short board of digital twin history data storage, can effectively restore the state and action of the digital twin body that has occurred to facilitate user to carry out effective visual analysis on abnormal situation.

Description

Technical Field

[0001] This invention relates to the field of digital twin data interaction, specifically to a method for constructing a historically traceable digital twin model, which belongs to the industrial field. Background Technology

[0002] With the advancement of intelligent manufacturing and the popularization of IoT technology, Digital Twin (DT) technology, which integrates multi-disciplinary, multi-perspective, multi-physical quantity, and multi-probability simulation processes by utilizing data such as sensor updates, physical models, and operational history, is increasingly being used in the industrial field and is considered a key technology for the Internet of Everything. Data interaction is a crucial link in the industrial field, and data interaction technologies include storage, compression, and transmission, mainly manifested in protocols and gateways, which are one of the core components of the digital twin data model.

[0003] Traditional digital twin construction methods primarily involve building virtual 3D models and data models to interface with data from the industrial site. This enables digital twins to perform functions such as data monitoring, fault prediction, and solution optimization of physical objects. The virtual 3D model provides visualization capabilities for users, while the data model forms the foundation for real-time data collection and processing by the digital twin.

[0004] However, current digital twin technologies primarily create digital twins that reflect the physical model in real time, but cannot reflect the past temporal state of the twin. Furthermore, while current digital twin models can alert and store abnormal data, they lack the ability to replay the historical data before and after an anomaly, hindering users from intuitively viewing the equipment's operational status and troubleshooting at the time of the anomaly. In addition, due to the complexity of digital twin model construction and the large volume and complex structure of historical data storage, a universal method for compressing historical data generated by digital twin models is needed. Summary of the Invention

[0005] This invention proposes a method for constructing a historically traceable digital twin model to address the following problems in current digital twin implementation schemes: inability to reflect the historical state and actions of the digital twin; inability to store massive amounts of historical data of the digital twin model; and inability to enable the digital twin to replay abnormal situations.

[0006] To address the aforementioned issues in constructing digital twins for industrial scenarios, this invention employs the following solution: A digital twin behavior model is constructed using AutomationML. Based on the input of the behavior model, a database storage model is automatically generated as a state package model; based on the output of the behavior model, a database storage model is automatically generated as an action package model. Combining these two models allows for the complete recording of the behavior model's state and actions. A dual-end storage rule is proposed to package state data in COLLADA standard and action data in JSON standard, compressing and storing the data in a historical database. A method for parsing historical data packets is proposed to restore historical data, extracting state data as real-time monitoring data for the digital twin dashboard, and injecting the action table into the digital twin 3D virtual model to render actions.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] This invention provides a modeling method based on AutomationML behavioral models.

[0009] We used AutomationML to build the digital twin behavioral model. AutomationML, based on an evaluation of existing data exchange formats, is a standardized data exchange format in digital manufacturing. It is a neutral, vendor-independent, scalable, open, and freely accessible data exchange format that enables consistent and lossless high-quality data exchange. As a digital twin behavioral model, AutomationML primarily involves geometric and kinematic information models. Geometric information describes the complete factory scene, while kinematic information describes the physical connections between 3D entities and the dependencies between objects. Therefore, we used the COLLADA standard format to store the data in this process. The behavioral model is the core of the digital twin model. Its input consists of device data uploaded from various device interfaces, converted using the OPCUA protocol into COLLADA format state data sets, including fields such as device name, device variables, device ID, and device status. The behavioral model itself is an abstract model of the entire digital twin model. AutomationML stores and manages the topology, geometry, logic, and process information of the production system in an object-oriented manner. It models the physical and logical components of the production system as data objects, organized in a hierarchical structure, ultimately forming a digital twin behavioral model containing various constraints. Its output is the JSON format action data variables of each component node of the digital twin's 3D virtual model, including coordinate axis position, rotation attributes, and dimension attributes. This is then rendered using the front-end Three.js 3D rendering engine. A schematic diagram is shown below. Figure 1As shown. The digital twin model includes a digital twin behavior model and a three-dimensional virtual model of the digital twin. The method includes the following:

[0010] The OPCUA protocol receives real-time scene data and integrates complex multi-source heterogeneous data, outputting it in COLLADA format, including the type, name, scope, and unit of the collected variables. In the AutomationML behavioral model, RoleClass defines the types of the internal components of the digital twin, including component scope, component name, and component type. InternalElement is a concrete instance inherited from RoleClass, which determines the component composition within the twin and supports hierarchical inclusion relationships, meaning that lower levels can contain more child instances InternalElement, referred to here as ChildElement, including instance name, instance scope, parent node, and child nodes. AttributeType defines the type of attribute, including attribute type name, attribute type description, and common attribute constraints. Attribute inherits from AttributeType and defines the instance's attributes. Attributes are attached to instances and are elements describing the instance's special attributes, including attribute name, attribute constraints, and attribute description. InterfaceClass defines the type of interface, including interface type name, interface data type, and interface description. ExternalInterface, as an inheritor of InterfaceClass, internally defines the constraints between instances, including input / output types, internal constraints, and interface protocols. The output of the behavioral model is action data in JSON format, including node ID, node name, variable type, variable content, unit, etc.

[0011] This invention provides a database construction method for automatically generating a data storage model for state data and motion data in a predetermined format. The database construction method includes the following steps: Parsing the input (INPUT) of the behavior model as state data in a COLLADA format file to extract state data variable information including fields such as device name, device variable, device ID, and device status; traversing the variable attributes of the state data variable information to generate a database storage model, which includes data information tables for each variable and a state data table (state package) summarizing all state data variables. Indexes and foreign keys are automatically established between the data information tables and the state data table, using GUID as the unique primary key. Parsing the output (OUTPUT) of the behavior model as motion data in a JSON format file to extract motion data variable information including fields such as coordinate axis position, rotation attributes, and size attributes; traversing the variable attributes of the motion data variable information to generate a corresponding database storage model, which includes a joint anchor point variable table, a motion data cache table, and a motion data variable table (motion package). The joint anchor point variable table includes information on each controlled joint anchor point in the digital twin 3D virtual model, including coordinate axis information, rotation angle, and translation scale. The motion data cache table contains all motion data from the previous time period. It is combined with the motion data variable table to render the motion effects of the digital twin 3D virtual model.

[0012] As a preferred technical solution, the database construction method should automatically create the following tables: a data information table, a status data table, a joint anchor point variable table, a motion data cache table, and a motion data table. The data information table should at least include the following fields: device ID, variable type, variable content, and data timestamp; the status data table should at least include the following fields: device ID, device name, device location, variable type, variable content, data timestamp, upper limit of variable, lower limit of variable, and whether it is abnormal; the joint anchor point variable table should at least include the following fields: coordinate axis information, rotation angle, and translation scale; the motion data cache table and the motion data table have the same fields and should at least include the following fields: node ID, node name, variable type, variable content, unit, and data timestamp.

[0013] This invention provides a dual-end storage rule for state data and behavior data. This dual-end storage rule requires that in industrial scenarios, the system needs to obtain a COLLADA-standard state data set from the input of a digital twin behavior model, and simultaneously obtain JSON-formatted action data from the output of the behavior model. For example... Figure 2 As shown, the method includes the following:

[0014] The rule pattern for dual-end storage includes the historical data acquisition time frequency (SetTimeOut), data compression method (DataCompression), and database construction method (DataBaseStructure). The time frequency specifies the acquisition frequency of historical data packets, representing the granularity of historical data storage. It is generally expressed using a CRON expression and needs to be set according to actual production needs. High-precision historical data storage of a long-unchanging twin can easily lead to a waste of computing and storage resources. The data compression method specifies the fusion compression method for dual-end storage. Since historical compressed packets need to be parsed, lossless compression methods are selected, including run-length encoding, Huffman coding, LZ777 algorithm, and LZ78 algorithm. Database construction methods typically involve collecting variable information from COLLADA and JSON files, including variable types, names, update frequencies, associated device information, and units; parsing the data to be stored in the database, usually using a non-relational database as the data storage solution; automatically creating corresponding tables in the database based on the parsed variable information; using GUIDs as unique primary keys; and automatically creating indexes and foreign keys.

[0015] As a preferred technical solution, the dual-end storage rules need to respond to anomalies in the twin database to record abnormal data. Furthermore, data within the timeframe before and after the timestamp of the anomaly point needs to be stored historically at the smallest possible time granularity to serve as the data foundation for subsequent fault backtracking and replay. The rule configuration for recording abnormal data includes the anomaly point interruption method, the timeframe before and after the anomaly, the smallest possible time granularity, and the anomaly database configuration method.

[0016] This invention provides a method for parsing historical data packets. The method includes the following steps: parsing historical data packets using a corresponding decoding method based on data compression; parsing to obtain COLLADA format files containing device status data such as device type, device variables, device ID, and device status; and parsing to obtain motion data in JSON format files containing node ID, node name, variable type, and variable content, for use in controlling the motion changes of a digital twin 3D virtual model. A GUI interface is built to display the current device status data of the digital twin. Motion changes of the digital twin 3D virtual model are rendered using a front-end 3D renderer.

[0017] This invention provides a method for constructing a historically traceable digital twin model, the overall flowchart of which is shown below. Figure 3 As shown, it includes the following steps:

[0018] S1. Load the behavioral model constraints into AutomationML to establish a digital twin behavioral model for industrial scenarios.

[0019] S2. Automatically generate a database storage model based on the input (INPUT) variables of the behavior model to store state data (state packet); automatically generate a database storage model based on the output (OUTPUT) of the behavior model to store action data (action packet).

[0020] S3. Use a dual-end storage rule to package and compress status data and action data into historical data packets and write them into the historical database for storage.

[0021] S4. Using the method of parsing historical data packets, the status packet is parsed out as the input data of the current digital twin model, and the action packet is injected into the rendering action of the three-dimensional virtual model of the data twin.

[0022] The beneficial effects of this invention are as follows:

[0023] The modeling method based on AutomationML behavioral models in this invention realizes the transformation of digital twin models from data models to geometric models. The dual-end storage rule for state data and behavioral data in this invention enables the storage of historical data generated by digital twins in industrial scenarios. The method for parsing historical data packets in this invention enables the historical backtracking and replaying of the digital twin model before and after abnormal states occur. Attached Figure Description

[0024] Figure 1 This is the model architecture of the behavioral model in an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of the storage process of the dual-end storage rule in an embodiment of the present invention;

[0026] Figure 3 This is an overall flowchart of the digital twin model construction method according to an embodiment of the present invention.

[0027] Figure 4 This is a schematic diagram of a historically traceable digital twin scenario according to an embodiment of the present invention. Detailed Implementation

[0028] The invention will be further illustrated below with a specific implementation example, which focuses on digital twin modeling of a dust removal equipment scenario in a factory. The specific implementation steps are as follows:

[0029] S1. Load the behavioral model constraints into AutomationML to create a digital twin behavioral model.

[0030] First, the input status data variables need to be determined, because the equipment data needs to be uniformly converted into COLLADA format via the OPCUA protocol. Therefore, equipment that supports the OPCUA protocol must be used. The status data acquisition variables for the entire dust removal equipment include, but are not limited to: fire extinguishing device water pressure (bar), dust collection hood pressure (Pa), fan total pressure (Pa), explosion-proof valve pressure resistance (Pa), dust collector pressure resistance (Pa), dust gas velocity (m / s), power (kW), and fan speed (rpm).

[0031] Next, the digital twin behavioral model is modeled. Components with common characteristics are first generalized and set as RoleClasses. For example, various valves in the equipment, which implement the opening and closing states of each passage, can be uniformly set as a valve class; various sensors in the equipment, which measure specific environmental variables, can be uniformly set as sensor classes. Then, the internal components of the dust removal equipment are instantiated and modeled. This step mainly involves formatting the internal components of the dust removal equipment according to the AutonomyML standard, clarifying the logical relationships between components. For example, "dust removal system - filter bag - wind speed sensor" is an instantiated component from top to bottom. Interfaces represent behavioral constraints between components. For example, the start / stop state of the compressed air manifold affects the wind speed and temperature in the pipeline; relevant formulas can be loaded into the interface to impose behavioral constraints. Finally, attribute types can be added to each instantiated component. For example, temperature and wind speed are basic attributes of each component in the dust removal system, which can be simulated and calculated from existing dot matrix sensor data.

[0032] Finally, the output motion data variables need to be determined, requiring the export of JSON-standard motion data from the nodes required by the digital twin 3D virtual model. Motion data variables for dust removal equipment include, but are not limited to: spray velocity (m / s) of the sprayer, spray angle of the sprayer, opening and closing of the explosion-proof valve, and the state of dust flow particles. This completes the construction of the entire AutomationML behavioral model.

[0033] S2. Automatically generate a database storage model based on the input (INPUT) variables of the behavior model to store state data (state packet); automatically generate a database storage model based on the output (OUTPUT) of the behavior model to store action data (action packet).

[0034] Based on the variable information in the COLLADA format file, it is mapped to the corresponding database table creation statements, and then the database execution statements are connected. This yields a status data table, an equipment table, a sensor table, and a sensor data table, etc. The status data table includes power information, on / off status, and sensor variable information for each device in the dust removal system; the equipment table includes equipment information and status information for devices such as fire extinguishing devices, dust collection hoods, fans, explosion-proof valves, and dust removal pipelines in the dust removal system; the sensor table includes status information and variable information for sensors such as dust detectors, temperature sensors, and spark detectors; and the sensor data variable table summarizes the status information of each sensor. Based on the variable information in the JSON standard file exported from the digital twin 3D virtual model, it is mapped to the corresponding database creation statements, and then the database execution statements are connected. This yields a joint anchor point variable table, a motion data cache table, and a motion data variable table, etc. The joint anchor point variable table includes information on each controlled joint anchor point in the digital twin 3D virtual model, including coordinate axis information, rotation angles, and translation scales. The motion data cache table contains all motion data from the previous time period. It is combined with the motion data variable table to render the motion effects of the digital twin 3D virtual model.

[0035] S3. Using a dual-end storage rule, status data and action data are packaged and compressed into historical data packets and written to the historical database for storage. Based on the rule pattern set in the dual-end storage rule, status packets and action packets at the same acquisition time are compressed and packaged into historical data packets according to a predetermined data compression method. The database table structure is then automatically reconstructed based on the structure of the newly generated historical data packets to adapt to the data packet storage requirements.

[0036] S4. Using the method of parsing historical data packets, the state packets are parsed out as the input data of the current digital twin model. The action packets are injected into the 3D virtual model of the data twin to render the action, restore the state data and action data of the past moment and load them into the GUI interface and 3D virtual model for retrospective replay.

[0037] The historical data packets are parsed according to the decoding method of the compression method set in the storage rules. This parsing extracts status data such as the water pressure of the fire extinguishing device, the pressure resistance of the ash collection hood, the total pressure of the fan, and the pressure resistance of the explosion-proof wire. This data is stored in the status database and displayed on the front-end GUI user interface. Joint anchor point variable information and action data are also parsed, such as the increase in the pipe particle index from 300 to 500, the change of the fire extinguishing device from closed to open, and the increase in the wind speed inside the pipe from 5 m / s to 10 m / s. These are then injected into the Three.js 3D engine for display and rendering, recreating the historical digital twin scene. Figure 4 As shown.

[0038] As a preferred technical solution, the web page is displayed while parsing historical data packets. The web implementation can use Three.js to display and render the digital twin 3D virtual model, and Vue + Element is chosen to build the GUI user interface.

[0039] The embodiments described above are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be understood that those skilled in the art can devise many other modifications and implementations, which will fall within the principles and spirit of this application.

Claims

1. A method for constructing a historically traceable digital twin model, characterized in that, Includes the following steps: S1. Load the behavioral model constraints into AutomationML to establish a digital twin behavioral model for the industrial scenario; the specific modeling method is as follows: AutomationML is used to build a digital twin behavior model, and the data is stored in the COLLADA standard format. The behavior model is the core of the digital twin model. Its input is the state data group in COLLADA format after the device data uploaded from each device interface is converted by OPC UA protocol. The behavioral model is an abstract model of the entire digital twin model. AutomationML models the physical and logical components in the production system as data objects. These data objects are organized in a hierarchical structure, ultimately forming a digital twin behavioral model containing various constraints. Its output is the JSON-formatted action data variables of each component node of the digital twin 3D virtual model; the digital twin model includes a digital twin behavior model and a digital twin 3D virtual model; S2. A database storage model is automatically generated based on the input variables of the behavioral model to store state data; a database storage model is automatically generated based on the output of the behavioral model to store action data; the database construction method includes the following: The input of the behavioral model is parsed as state data in COLLADA format to extract state data variable information. The variable attributes of the state data variable information are traversed to generate a database storage model. This storage model includes a data information table for each variable and a state data table summarizing all state data variables. Indexes and foreign keys are automatically established between the data information table and the state data table, with GUID as the unique primary key. The output of the behavior model is parsed as motion data in a JSON format file to extract motion data variable information. The variable attributes of the motion data variable information are traversed to generate a corresponding database storage model. This storage model includes a joint anchor point variable table, a motion data cache table, and a motion data variable table. The joint anchor point variable table includes the information of each controlled joint anchor point in the digital twin 3D virtual model. The motion data cache table contains all motion data from the previous time. Combined with the motion data variable table, the motion effects of the digital twin 3D virtual model are rendered. S3. Use a dual-end storage rule to package and compress status data and action data into historical data packets and write them to the historical database for storage; the dual-end storage rule includes the following: The rule pattern of dual-end storage includes the time frequency of historical data collection, data compression method, and database construction method; The time frequency specifies the collection frequency of historical data packets, representing the granularity of historical data storage. It is expressed using the CRON expression and requires parameter setting based on actual production needs. The data compression method specifies the fusion compression method for dual-end storage. Since historical compressed packets need to be parsed, a lossless compression method is selected. The database construction method collects variable information from COLLADA and JSON files, specifically including the variable type, variable name, update frequency, associated device information, and unit. It then parses the database information to be stored, using a non-relational database as the data storage solution. Based on the parsed variable information, corresponding tables are automatically created in the database. A GUID is used as the unique primary key, and indexes and foreign keys are automatically created. S4. Using the method of parsing historical data packets, the status packet is parsed out as the input data of the current digital twin model, and the action packet is injected into the rendering action of the three-dimensional virtual model of the data twin.

2. The method for constructing a historically traceable digital twin model according to claim 1, characterized in that, The database construction method should automatically create the following tables: data information table, status data table, joint anchor point variable table, motion data cache table, and motion data table; the data information table should at least include the following fields: Device ID, variable type, variable content, data timestamp; The status data table should at least The following fields should be included: Device ID, Device Name, Device Location, Variable Type, Variable Content, Data Timestamp, Variable Upper Limit, Variable Lower Limit, and Whether it is Abnormal; the joint anchor point variable table should at least include the following fields: coordinate axis information, rotation angle, and translation scale; The action data cache table and the action data table have the same fields, and should at least include the following fields: node ID, node name, variable type, variable content, unit, and data timestamp.

3. The method for constructing a historically traceable digital twin model according to claim 1, characterized in that, The dual-end storage rules need to respond to anomalies in the twin to record abnormal data. In addition, data within the time range before and after the timestamp of the anomaly point needs to be stored historically at the smallest time granularity to serve as the data basis for subsequent fault backtracking and replay. The rule configuration for recording abnormal data includes the anomaly point interruption method, the time range before and after the anomaly, the smallest time granularity, and the anomaly database configuration method.

4. The method for constructing a historically traceable digital twin model according to claim 1, characterized in that, The methods for parsing historical data packets include the following: Historical data packets are parsed using a corresponding decoding method based on data compression. This process extracts COLLADA format files containing device status data (including device type, device variables, device ID, and device status) and JSON format files containing node ID, node name, variable type, and variable content. These JSON-formatted action data are then used to control the movement and changes of the digital twin's 3D virtual model. A GUI interface is built to display the current device status data of the twin. Finally, a front-end 3D renderer is used to render the movement and changes of the digital twin's 3D virtual model.

Images