Cross-environment sharing method and device for business data of Internet of Things, and medium

Abstract

The embodiment of the invention discloses a cross-environment sharing method and device for business data of the Internet of Things, and a medium, and relates to the technical field of the Internet of Things, and the method comprises the steps: in an export environment node, according to at least one user demand business application of cross-environment sharing request information triggered by a user, sending the business application to a server; determining a business data FTK packet corresponding to the business application required by the user; when the business data FTK packet is imported into a plurality of import environment nodes in the cross-environment sharing request information, generating a decentralized model code corresponding to each business application model in the business data FTK packet, updating an abstract file in the business data FTK packet by using the decentralized model code, and determining an updated abstract file; and verifying the received business data FTK packet according to the updated abstract file through a plurality of import environment nodes, and importing the business application model set in the business data FTK packet in the import environment nodes passing the verification, thereby realizing cross-environment sharing of the business data of the Internet of Things.

Description

Technical Field

[0001] This specification relates to the technical field of the Internet of Things, and particularly to a method, device, and medium for cross-environment sharing of Internet of Things service data. Background Art

[0002] The cross-environment migration and sharing of Internet of Things service data have significant advantages and necessity in a complex Internet of Things ecosystem. Internet of Things devices are often deployed in environments with different technology stacks. Cross-environment migration and sharing can break data islands and achieve data interconnection across multiple platforms. In addition, the business requirements of the Internet of Things change rapidly (such as device protocol upgrades and new monitoring indicators). Migration and sharing allow for flexible adjustment of the data distribution scope. For example, in a smart city, a traffic flow model needs to be migrated from a test environment to a production environment and synchronized to multiple regional nodes.

[0003] The business data generated by the Internet of Things platform includes database data and file data, which is large in volume, involves many data tables, and has a complex data structure. If traditional database operations are used for data migration and sharing, the efficiency is low and errors are likely to occur. The traditional business data sharing process is often centralized, relying on a centralized control node and storage system, with poor anti-attack ability and fault tolerance, and it is difficult to ensure data security, resulting in a significant increase in the cost and difficulty of operation and maintenance management. In addition, most migration and sharing methods require users to directly operate the underlying data storage, database, and file system, and most of them are full-scale migrations of data. Users cannot flexibly select the data they need for selective migration and sharing according to the actual business scenario. During the full-scale migration process, some business data contains environment-sensitive information, posing data security problems. In addition, in the vast majority of data sharing methods, the data exists independently of the application, and the data is like a black box to the application. If there is a large difference between the version of the application and the data, it will cause abnormal function operation. Therefore, in the cross-environment sharing scenario between different environments, the traditional migration and sharing method requires full-scale migration operations on the underlying data. The Internet of Things service data is relatively separated from the Internet of Things service application scenario, and there are risks of data tampering and incompatibility of the migration environment, resulting in abnormal operation of business functions. Summary of the Invention

[0004] One or more embodiments of this specification provide a method, device, and medium for cross-environment sharing of Internet of Things service data to solve the following technical problems: In the cross-environment sharing scenario between different environments, the traditional migration and sharing method requires full-scale migration operations on the underlying data. The Internet of Things service data is relatively separated from the Internet of Things service application scenario, and there are risks of data tampering and incompatibility of the migration environment, resulting in abnormal operation of business functions.

[0005] One or more embodiments of this specification adopt the following technical solutions: One or more embodiments of this specification provide a method for cross - environment sharing of Internet of Things service data. The method includes: in an export environment node, determining a service data FTK package corresponding to the user - required service application according to at least one user - required service application in the cross - environment sharing request information triggered by the user, where the service data FTK package includes an abstract file and a set of service application models corresponding to the user - required service application; when importing the service data FTK package into multiple import environment nodes in the cross - environment sharing request information, generating a decentralized model code corresponding to each service application model in the service data FTK package, and updating the abstract file in the service data FTK package with the decentralized model code to determine an updated abstract file; through the multiple import environment nodes, verifying the received service data FTK package according to the updated abstract file, and in the import environment nodes where the verification passes, importing the set of service application models in the service data FTK package to achieve cross - environment sharing of Internet of Things service data.

[0006] One or more embodiments of this specification provide a device for cross - environment sharing of Internet of Things service data, including: At least one processor; and, A memory communicatively connected to the at least one processor; where, The memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is enabled to execute the above - mentioned method.

[0007] A non - volatile computer storage medium provided by one or more embodiments of this specification stores computer - executable instructions, and the computer - executable instructions are set to: execute the above - mentioned method.

[0008] The above at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: Through the technical solution provided by the embodiments of this specification, users can select specific business applications through the check box interface according to actual business needs, automatically associate the required data tables and dependent files, avoid the redundancy of full-scale migration, and solve the problem of resource waste in traditional full-scale migration; In the export environment node, business data modeling is carried out from the perspective of Internet of Things business applications, realizing the integrated encapsulation of business logic and data; The generation of the model code completely depends on the characteristics of the node itself and the model content, without the need for a centralized agency to allocate, avoiding the risk of single-point control. By modeling the Internet of Things business applications and formulating a unique identity for the data model - a decentralized model code, the exported objects contain specific data and self-descriptive summary information, and each node can independently generate, verify, and manage the identity of the data model; In different application environments, based on unified rules, the generation and migration processes of business application models are managed, including modeling methods, model registration, version verification rules, extension processing logics, etc., ensuring the consistency of the behavior of business data when flowing through each node; Each business application model is uniquely identified by a decentralized model code and relies on multi-node distributed verification to replace the single-point control of the traditional centralized server, reducing the risk of data tampering, and the fault tolerance is significantly better than the traditional centralized solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. In the drawings: Figure 1 It is a schematic flowchart of a method for cross-environment sharing of Internet of Things business data provided by the embodiments of this specification; Figure 2 It is a schematic structural diagram of a business data FTK package provided by the embodiments of this specification; Figure 3 It is a schematic flowchart of a double version verification provided by the embodiments of this specification; Figure 4 It is a schematic diagram of an application scenario of a method for cross-environment sharing of Internet of Things business data provided by the embodiments of this specification; Figure 5 It is a schematic structural diagram of a device for cross-environment sharing of Internet of Things business data provided by the embodiments of this specification. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0010] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0011] The embodiments of this specification provide a method for cross - environment sharing of Internet of Things service data. It should be noted that the execution subject in the embodiments of this specification can be a server or any device with data - processing capabilities. Figure 1 It is a schematic flowchart of a method for cross - environment sharing of Internet of Things service data provided by the embodiments of this specification, as Figure 1 shown, mainly including the following steps: Step S101, in the export environment node, determine the business data FTK package corresponding to the user - required service application according to at least one user - required service application in the cross - environment sharing request information triggered by the user.

[0012] Among them, the business data FTK package includes an abstract file and a set of service application models corresponding to the user - required service application; In an embodiment of this specification, in the method for cross - environment sharing of Internet of Things service data, when a user needs to migrate the data of a specific service application to another environment, a cross - environment sharing request information is triggered. The cross - environment sharing request information includes the user - required service application that the user needs to migrate and share, and the target environment of this migration and sharing process, that is, the import environment node. According to at least one user - required service application in the cross - environment sharing request information triggered by the user, determine the business data Fast Tool Kit (FTK) package corresponding to the user - required service application. The business data FTK package includes an abstract file and a set of service application models corresponding to the user - required service application.

[0013] Based on at least one user requirement business application of the cross-environment sharing request information triggered by the user, determine the business data FTK package corresponding to the user requirement business application, specifically including: extracting application features corresponding to multiple business application types, determining a general modeling strategy, where the application type of the user requirement business application includes any one or more of data collection business applications, data calculation business applications, and data display business applications, and the general modeling strategy includes data items, configuration items, and dependency file items; based on the user requirement business application and the general modeling strategy, perform data retrieval in the export environment node to construct a general business application model corresponding to the user requirement business application, where the configuration items in the general business application model are preset values; obtain the environment-sensitive information corresponding to each import environment node triggered by the user, and through the environment-sensitive information, perform environment adaptation configuration on the configuration items of the general business application model to determine the business application model corresponding to each user requirement business application; assemble multiple business application models to generate the business data FTK package corresponding to the user requirement business application.

[0014] Traditional modeling methods usually perform modeling at the data level. In the embodiments of this specification, in the export environment node, business data modeling is performed from the perspective of Internet of Things business applications. The actual business scenarios in the Internet of Things field mainly include device data collection business applications, device data real-time calculation business applications, and device data visualization display business applications. Among them, the device data collection business application contains data such as access protocols, device models, device lists, and codec plugins, the device data real-time calculation business application contains data such as trigger rules, calculation rules, and output rules, and the device data visualization display business application contains data such as visualization canvas structures, materials, and data sets. By extracting the commonalities of each business application, a modeling method of "data + configuration items + dependencies" is proposed. The data is the basic data in this business scenario, such as data collection protocol types, device model structures of device data, device information, etc.; the configuration items are unique scenario configuration data in the actual scenario, such as IP addresses and port numbers for network communication; the dependencies are the dependency files for the data to take effect, including jar packages, pictures, etc. When generating the Internet of Things business application model, the data and dependencies remain unchanged. Since the configuration items are strongly related to the actual environment, default values will be uniformly set in the model to ensure that environment-sensitive information is not leaked. During data migration, through a guided interface operation, users can separately configure the configuration items for each business application and fill in the current environment-sensitive information such as network communication and database connection. When data export is required, users do not need to pay attention to the underlying data tables and data structures. They only need to check the business applications they need on the function interface, and the automated program will retrieve the database data and file data to generate the Internet of Things business application model. Figure 2This is a schematic diagram of the structure of a business data FTK package provided by an embodiment of this specification. Multiple business models are assembled, and the export is a business data FTK package corresponding to the business application of user requirements. For example, Figure 2 As shown, the business data FTK package includes business application models corresponding to multiple business application types, and each business application model includes multiple business models. For example, in the business application model of data collection, it includes a temperature data collection business model and an image data collection business model. According to each business application model, a corresponding summary file is generated. Here, the summary file is used to self-describe the business application model information.

[0015] Taking the business application of device data collection as an example for illustration, the basic data of this business scenario is extracted and standardized and packaged. For example, in the business of device data collection, the object model structure (JSON Schema), device list (CSV format), and protocol definition (XML file) are packaged in a read-only form to ensure that the core business logic cannot be tampered with. The dynamic parameters strongly related to the environment (such as the IP address and port number of the data collection service) are replaced with placeholders (such as ${IP_ADDRESS}) to generate a configuration template without actual sensitive values. This process avoids storing production environment information in plain text and eliminates the risk of data leakage from the source. The static dependency files required for the operation of the business application (such as protocol encoding and decoding JAR packages, device driver libraries) are collected and stored in a compressed binary form to ensure that the dependency versions strictly match the business logic. When the user checks multiple business applications through the graphical interface, such as migrating data collection and visualization applications at the same time, according to the selected business applications, the database and file system are automatically scanned to accurately locate the associated data tables, such as the device information table, alarm record table, etc., and dependency files, such as the visualization component library. Multiple business models are assembled, and the integrated business application model (data, configuration template, dependencies) and the summary file (including unique identifier, version number, data fingerprint) are packaged into a business data FTK package, which is output in an encrypted and compressed format to ensure the security and integrity of the transmission process. When importing the FTK package into the target environment, the user is guided through a guided interface to dynamically fill in the configuration items. The user fills in the configuration items according to the actual parameters of the current environment, such as the target database IP, account password, etc., and the system automatically replaces the placeholders to generate a configuration file exclusive to the environment. Check whether the required dependencies, such as a specific version of the protocol parsing library, are installed in the target environment. If missing, trigger a secure download process to ensure the consistency of the operating environment.

[0016] Through the above technical solution, business data modeling is carried out from the perspective of Internet of Things business applications, deeply binding data, configuration items and dependencies with specific business scenarios, and realizing the integrated encapsulation of business logic and data. For different types of business applications, through predefined general modeling strategies, the core data required by business scenarios is automatically associated, avoiding the redundancy of traditional full-scale migration. After the user checks the business application through the interface, the system automatically retrieves the database and file system, constructs a general business application model according to the strategy, presets default values for configuration items, and dynamically fills in actual parameters according to the target environment during migration, realizing "one-time modeling, multi-environment adaptation", and reducing the cost of repeated operations. Configuration items are encapsulated with preset values during the modeling stage, and the user inputs target environment parameters through a guided interface during migration to ensure that sensitive information does not spread with the model. Dependent files are solidified in the model and strictly match the business logic, avoiding functional abnormalities caused by differences in environment-dependent versions. Users do not need to understand the underlying data structure or write migration scripts, but only need to check the business application through the graphical interface to automatically complete data retrieval, model construction and adaptation. Through business semantic encapsulation and dynamic environment adaptation, problems such as low efficiency, security risks and lack of flexibility in traditional data migration are solved.

[0017] Step S102, when importing the business data FTK package into multiple import environment nodes in the cross-environment sharing request information, generate a decentralized model code corresponding to each business application model in the business data FTK package, and update the summary file in the business data FTK package with the decentralized model code to determine the updated summary file.

[0018] In an embodiment of the present specification, when importing the business data FTK package into multiple import environment nodes in the cross-environment sharing request information, calculate and generate a unique identification code corresponding to each business application model in the business data FTK package, that is, the decentralized model code, create an independent entry for each business application model in the summary file, record its corresponding decentralized model code, and associate metadata such as the version number and creation time of the model.

[0019] Generate the decentralized model codes corresponding to each business application model in the business data FTK package, specifically including: in the export environment node, based on the node environment parameters corresponding to the export environment node, generate the time gene identifier and node gene identifier corresponding to the export environment node, where the node environment parameters include node clock feature information and node physical feature information; obtain the model metadata corresponding to each business application model, perform a hash calculation on the model metadata to determine the data gene identifier corresponding to the business application model; according to a preset encoding method, generate the decentralized model code corresponding to each business application model for the time gene identifier, the node gene identifier, and the data gene identifier; use the decentralized model code corresponding to each business application model as the primary key to perform model registration in the model registry preset in the export environment node, and record the export record corresponding to the business application model.

[0020] In an embodiment of the present specification, based on the node environment parameters of the export environment node, a globally unique node gene identifier is generated. The current timestamp is obtained through a high-precision clock at the microsecond level, combined with an atomic incrementing serial number, to form a unique encoding in the time dimension, ensuring that the identifiers generated by the same node at different times are absolutely unique. The hardware feature information and physical location information of the node are extracted. The hardware feature information includes the MAC address and device serial number, and the physical location information includes GPS coordinates and IP address. After being processed by a collision-resistant hash algorithm, an irreversible physical fingerprint is generated to ensure that the node identity cannot be forged. For each business application model, the core metadata is extracted from the model, including business logic definitions, dependency lists, and configuration templates. After normalizing the metadata through operations such as field sorting and null value filling, an encrypted hash operation (such as SHA-256) is performed to generate a data gene identifier, ensuring that the model content is strictly bound to the hash value, and any data tampering will cause the identifier to become invalid. The original byte stream is concatenated in the order of the time gene identifier, the node physical gene identifier, and the data gene identifier, retaining the complete information of each part. A secondary hash operation is performed on the concatenated byte stream to generate the final model code, ensuring that the model code has the ability to resist quantum computing attacks and the original parameters cannot be obtained through reverse derivation.

[0021] Use the generated decentralized model code as the primary key to perform persistent storage in the local model registry of the export environment node. The local model registry structure includes information such as the primary key, metadata fields, and export records. The primary key is the globally unique decentralized model code; the metadata fields record the model version number, creation time, and hash value of the data gene identifier; the export record records the list of target environment nodes, operator identity, and timestamp of the current export.

[0022] Through the above technical solution, the generation of the model code completely depends on the node's own features and model content, without the need for a centralized institution to allocate, avoiding the risk of single-point control. The data gene identifier and the secondary hashing mechanism ensure a strong association between the model content and the identifier, and any data modification will cause the identifier to become invalid. The export records and version information in the model registry support cross-environment auditing, and can quickly locate the source of tampering behavior or version conflicts. The dynamic generation mechanism of the node physical gene identifier adapts to heterogeneous hardware environments, such as Xinchuang devices and general servers, ensuring seamless operation in the domesticated scenario. In addition, by modeling the IoT business applications and formulating a unique identity identifier for the data model - the decentralized model code, the exported objects contain specific data and self-descriptive summary information, and each node can independently generate, verify, and manage the identity of the data model. In different application environments, based on unified rules, the generation and migration processes of the business application models are managed, including modeling methods, model registration, version verification rules, extension processing logics, etc., ensuring the consistency of the behavior of business data when flowing through each node.

[0023] Step S103: Through multiple import environment nodes, verify the received business data FTK package according to the update summary file. In the import environment nodes where the verification passes, import the business application model set in the business data FTK package to achieve cross-environment sharing of IoT business data.

[0024] Through multiple such import environment nodes, verify the received business data FTK package according to the update summary file, specifically including: when the current import environment node receives the business data FTK package, construct an import node channel between the current import environment node and other import environment nodes according to the multiple import environment nodes in the cross-environment sharing request information, where the import node channel automatically disconnects after a preset duration; perform an environment node signature on the update summary file of the business data FTK package in the current import environment node to generate signature summary information, and perform an inter-transmission operation on the signature summary information with other import environment nodes through the import node channel; perform signature verification and summary information consistency verification on the received signature summary information through the current import environment node to determine the number of nodes that pass the verification; when the number of nodes exceeds the preset dynamic node threshold, determine that the verification of the business data FTK package received by the current import environment node passes.

[0025] In one embodiment of this specification, when the business data FTK package is imported into multiple import environment nodes, after the current import environment node (Node A) receives the business data FTK package, it parses the target node list (such as Node B, C, D) in the cross-environment sharing request information and establishes a temporary encrypted channel with these nodes through the P2P protocol. This channel adopts a two-way authentication mechanism to ensure communication security. The channel automatically disconnects after a preset duration (such as 300 seconds) to release network resources. If the verification is completed during this period, it will be closed in advance; if it times out without completion, an exception alarm will be triggered and a log will be recorded. Node A locally signs the update summary file in the FTK package, extracts the core fields of the summary file, such as data gene identification and version number, generates a digital signature using the private key of the node, and forms signature summary information, including the signature value, timestamp, and node ID. The signature summary information is broadcast to other import nodes (B, C, D) through the temporary channel, and at the same time, the signature summary information returned by these nodes is received.

[0026] Search for the public keys of each node from the pre-stored list of trusted public keys to verify whether the signature is generated by the corresponding private key and has not been tampered with. Compare the content of the summary files returned by all nodes to ensure that the key fields (such as data hash, model version) are exactly the same. Dynamically calculate the threshold according to the total number of participating nodes, which can be set to 2 / 3 of the total nodes. For example, if there are 5 nodes in total, at least 4 nodes need to pass the verification. Count the number of nodes that pass the verification. If it exceeds the threshold, it is determined that the FTK package verification is legal and the import is allowed; otherwise, it is marked as risk data, isolated, and an artificial review process is triggered.

[0027] Reducing resource occupation through the time-limited channel can prevent network congestion or an enlarged attack surface caused by long-term connections. The signature legality verification ensures the credibility of node identities, the summary consistency comparison prevents data tampering, the double verification enhances the defense level, and the threshold is dynamically adjusted based on the number of nodes to adapt to different-scale network environments, ensuring that the majority of honest nodes dominate the verification results. Through the above technical solutions, the migration security in the decentralized migration process is improved.

[0028] In one embodiment of this specification, an import environment node that passes the verification indicates that the received business data FTK package is the content that needs to be migrated and shared, and there are no problems affecting data security such as tampering during the migration process. In such import environment nodes, the business application model set in the business data FTK package is imported to achieve cross-environment sharing of Internet of Things business data.

[0029] In the imported environment nodes that pass the verification, import the set of business application models in the business data FTK package of this service, specifically including: retrieve in the local model registry of each of these imported environment nodes according to the decentralized model code in this update summary file; when the decentralized model code cannot be retrieved in the local model registry, use the decentralized model code corresponding to this business application model as the primary key to register the model in the local model registry, and perform the first import of the corresponding business application model; when the decentralized model code is retrieved in the local model registry, use the decentralized model code as the primary key to determine the version information of the corresponding business application model in the local model registry; according to this business application model version information, perform version verification in this imported environment node to determine the model availability of this business application model, so as to perform an update import of the available model in the imported environment node.

[0030] In an embodiment of this specification, the import node first parses the decentralized model code (globally unique identifier) in the update summary file and retrieves it in the locally maintained model registry. The registry uses the model code as the primary key and stores core metadata such as the version number, data fingerprint, and import time of the model. If the model code cannot be retrieved, it means there is no matching record in the local registry, indicating that this model is imported for the first time. Then, use this model code as the primary key to create a new registration entry, record the initial version number (such as v1.0.0), data hash value, and import time; write the business application model (including data tables, configuration file templates, dependencies) into the local database and file system. If the model code is retrieved, that is, the same model code already exists locally, then determine the version information of the corresponding business application model in this local model registry; according to this business application model version information, perform version verification in this imported environment node to determine the model availability of this business application model, so as to perform an update import of the available model in the imported environment node. The decentralized model code is the basis for realizing the decentralization of the data migration process, which enables each environment to independently store and manage the identity identifier of the model according to the rules, without relying on a centralized authoritative institution. The business model can flow and change in different environments, but the decentralized model code remains unchanged, greatly improving the flexibility and traceability of the data migration process; when the IoT business application model is exported or imported, a copy will be retained in the current environment and information will be registered, avoiding the dependence on centralized storage. The loss or tampering of data on a single node will not affect the data stability of all systems, ensuring data security, realizing the decentralization of the business data migration process, effectively avoiding the disadvantages of traditional migration methods, ensuring data anti-tampering, and enhancing system stability and data security.

[0031] During the traditional business data migration process, the data exists independently of the application. However, with the iteration of the application, the generated data structure usually changes significantly. If the application versions in environment A and environment B differ greatly, after migrating the data in environment A to environment B, it often causes abnormal operation of the system in environment B and affects user experience. In addition, for the case where the same model code already exists locally, there may be a situation where the business application model of a lower version overwrites the business application model of a higher version, thus affecting the actual business operation after the business data is shared.

[0032] According to the version information of the business application model, perform version verification in the import environment node to determine the model availability of the business application model, specifically including: obtaining the local model version information corresponding to the business application model in the local model registry and the environment application deployment version information of the import environment node; based on the local model version information and the environment application deployment version information, perform dual-version verification on the business application model to determine the model availability of the business application model.

[0033] In an embodiment of this specification, if the same model code already exists locally, obtain the local model version information corresponding to the business application model existing locally and the environment application deployment version information deployed in the current environment.

[0034] Based on the local model version information and the environment application deployment version information, perform dual-version verification on the business application model to determine the model availability of the business application model, specifically including: verifying the version information of the business application model through the environment application deployment version information to determine the application version verification status of the business application model; when the environment application deployment version information is not lower than the version information of the business application model, determine that the application version verification status is verified; verify the version information of the business application model through the local model version information; when the version information of the business application model is not lower than the local model version information, determine that the business application model is an available model.

[0035] Figure 3 It is a schematic diagram of the verification process for dual-version verification provided by the embodiment of this specification, as Figure 3 shown, through the environment application deployment version information, that is, Figure 3 the current application Version in Figure 3Import the FTK package Version = 6.5 in it for verification to determine the application version verification status of the business application model. When the current application Version is not lower than the FTK package Version 6.5, it indicates that the application deployment version in the current environment is not lower than the version of the business application model and is in an out-of-the-box state, that is, the application version verification is passed. When the current application Version is lower than the FTK package Version 6.5, it indicates that the current application version is too low to support the normal operation of the migrated business application model. The import of the business model can be completed by triggering the application version upgrade in the current environment to ensure that the current application version can implement the business application. Under the condition that the application version verification is passed or when the application upgrade is triggered, the version information of the business application model is verified through the locally deployed model version in the current environment obtained by pre-judgment, that is, the local model version information corresponding to the business application model in the local model registry. When the business application model version information is not lower than this local model version information, it indicates that the business application model to be migrated is the latest version model, and this business application model is determined to be an available model, and the model is updated to avoid the situation where a low-version business application model overwrites a high-version business application model.

[0036] Through the technical solution of the embodiments of this specification, during the program operation, the application version is automatically recorded. Moreover, due to the data modeling method of the Internet of Things business application model, the model data can correspond one-to-one with the application modules. When exporting data, the application program can obtain the version information of the current business data, output it to the summary file of the business model, and write it into the version field of the model registry in the current environment. When the business application model is imported into a new environment, the application program verifies the version number in the FTK package summary file with the version number of the application module in the current environment. Only when the verification passes will the data be imported into the current environment. Through the innovative design of the dual-version verification mechanism and data-application integrated modeling, the problems of system operation anomalies and data conflicts caused by version differences in traditional data migration are effectively solved. Before importing the business application model, first verify whether the application deployment version of the target environment supports the model, completely eliminating the problem that the model cannot run or the function is abnormal due to too low an application version. After the application version verification is passed, further verify the model version to prevent the low version from overwriting the high version data; through the encapsulation of the Internet of Things business application model, the data, configuration items, dependencies and specific business logics are deeply associated to eliminate system anomalies caused by version differences, ensure seamless operation of the migrated business, reduce manual intervention, improve the operation and maintenance efficiency and reliability, and meet the requirements of data sovereignty and privacy protection regulations through version binding and operation traceability.

[0037] After importing the set of business application models in the business data FTK package, the method further includes: when the import environment node modifies a specified business application model in the set of business application models, recording a modification log corresponding to the specified business application model in the model registry of the import environment node; when receiving an export request for the specified business application model, generating a summary file corresponding to the specified business application model through the modification log.

[0038] In traditional data migration methods, different environments are unaware of data modifications. As the number of data migrations increases and the migration scope expands, the data between different environments will become uneven, and it is impossible to trace data change records, resulting in problems such as data inconsistency and system docking errors, increasing the cost of data management and maintenance.

[0039] In an embodiment of this specification, the idea of decentralization improves the flexibility of business data migration. To ensure stability during use, functions such as model data modification logs, model state backtracking, and operation auditing are implemented. Based on the unified identity identifier of the model, after each environment modifies the model, a modification log will be recorded in the model registry and written into the summary file of the export object as the model is exported. When the model flows to other environments, the modification log will also be shared, realizing data state backtracking during the decentralized business data migration process. When the import environment node modifies an imported specified business application model, such as adjusting the physical model structure or updating the calculation rule, the operation type, modification content, operator identity, timestamp, version evolution chain, etc. will be automatically recorded in the local model registry. The operation type includes specific operations such as addition, modification, and deletion. The modification content is the old value and the new value of the changed field. For example, the protocol port number is changed from 8080 to 8090. The operator identity is used to identify the user or system module that executes the modification through a digital certificate. The timestamp is the operation time accurate to the millisecond level. The version evolution chain is used to record the new version number after this modification, such as upgrading from v1.2.0 to v1.2.1. The modification log is stored in a structured format (such as JSON) and bound to the decentralized model code of the unified identity identifier of the model to ensure that each record can be accurately associated with a specific model.

[0040] When the user triggers an export request for a specified business application model, retrieve all the modification logs of the model from the model registry, and generate an operation history chain sorted by time; write the operation history, the latest version number, and the data fingerprint (model content hash value) into the summary file of the FTK package to form a complete auditable trace record; perform a node digital signature on the updated summary file and encrypt it with the public key of the target environment node to ensure the security of the transmission process. When the model is migrated to other environment nodes, the modification logs in the summary file are synchronously distributed along with the FTK package. After receiving, the import node merges the logs into the local registry to build a globally unified version evolution view. Users can quickly locate historical changes (such as configuration adjustments at a specific time point) by viewing the modification logs and support rolling back to any stable version as needed. If conflicts are detected in the modifications of the same model in different environments (such as a field being deleted at node A while being modified at node B), the conflict items can be automatically marked and an artificial review process can be triggered.

[0041] Through the above technical solutions, based on the uniqueness of the decentralized model code, it is ensured that each business application model has an immutable identity identifier during cross-environment migration. Any data change is bound to the model code to prevent data tampering or version confusion; the modifications to the model in each environment are recorded in the local registry and synchronized to other nodes along with the FTK package summary file to form a globally unified version evolution chain; each model modification records the operation type, the identity of the operator, the timestamp, and the changed content. When the model is migrated to a new environment, it carries a complete modification log, and users can quickly roll back to any historical version; each node can independently modify the model, and at the same time, through the sharing of modification logs, distributed collaboration is achieved, avoiding the single-point failure risk of the traditional centralized architecture.

[0042] In addition, in traditional data migration methods, operations are usually directly performed on database tables. In the Xinchuang environment, there are significant differences in database field types, and data loss often occurs after migration. In an embodiment of this specification, when exporting data, although there are differences in the table data field structures in the business model, during import, the automated program can identify the database type of the current environment, create an executor compatible with the current database type through the factory pattern, convert the table data into a form that can be recognized by the current database, and perform subsequent insert or update operations. This shields the differences in underlying data storage, and users only need to focus on the actual business meaning without considering the database type used in the current environment, facilitating the migration and sharing of IoT business application data in different environments.

[0043] Figure 4 A schematic diagram of the application scenario of a cross-environment sharing method for IoT business data provided by the embodiments of this specification is as Figure 4As shown in the figure, after constructing the IoT business application model in Environment A, an FTK package is generated, imported into Environment C, and stored. When the IoT business application model in Environment C needs to be shared and migrated to Environment D, the IoT business application model is constructed in Environment C, an FTK package is generated, and shared to Environment D. When the application model is modified in Environment D and re-migrated and shared to Environment A, an FTK package is generated. Environment A is the import environment, belonging to the same model coverage scenario, and the local model registration information is updated.

[0044] Through the technical solution provided by the embodiments of this specification, users can select specific business applications through the check box interface according to actual business needs, automatically associate the required data tables and dependent files, avoid the redundancy of full-scale migration, and solve the problem of resource waste in traditional full-scale migration; in the export environment node, business data modeling is carried out from the perspective of the IoT business application, realizing the integrated encapsulation of business logic and data; the generation of the model code completely depends on the characteristics of the node itself and the model content, without the need for a centralized institution to allocate, avoiding the risk of single-point control. By modeling the IoT business application and formulating the unique identity of the data model - the decentralized model code, the exported object contains specific data and self-descriptive summary information, and each node can independently generate, verify, and manage the identity of the data model; in different application environments, based on unified rules, the generation and migration process of the business application model are managed, including the modeling method, model registration, version verification rules, extension processing logic, etc., ensuring the consistency of the behavior of business data when flowing through each node; each business application model is uniquely identified by the decentralized model code and relies on multi-node distributed verification to replace the single-point control of the traditional centralized server, reducing the risk of data tampering, and the fault tolerance is significantly better than the traditional centralized solution.

[0045] The embodiments of this specification also provide a cross-environment sharing device for IoT business data, such as Figure 5 shown in the figure. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the above method.

[0046] The embodiments of this specification also provide a non-volatile computer storage medium storing computer-executable instructions, and the computer-executable instructions are set to: execute the above method.

[0047] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments. In particular, for the embodiments of devices, equipment, and non-volatile computer storage media, since they are basically similar to the method embodiments, the description is relatively simple, and reference can be made to the relevant parts of the method embodiments for the related content.

[0048] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0049] The devices and media provided in the embodiments of this specification correspond one-to-one with the methods. Therefore, the devices and media also have beneficial technical effects similar to those of their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be elaborated here.

[0050] Those skilled in the art should understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) that contain computer-usable program code.

[0051] This specification is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0052] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device that implements the function specified in one or more of the processes and / or blocks Figure 1 one or more of the processes and / or blocks Figure 1 specified in one or more of the blocks or blocks.

[0053] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, such that a series of operational steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable apparatus provide steps for implementing the function specified in one or more of the processes and / or blocks Figure 1 one or more of the processes and / or blocks Figure 1 specified in one or more of the blocks or blocks.

[0054] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0055] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM) and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

[0056] Computer-readable media includes both permanent and non-permanent, removable and non-removable media implemented by any method or technology for storing information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0057] It should also be noted that the term "comprising", "including" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements not only includes those elements but also other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising said element.

[0058] The above is only one or more embodiments of this specification and is not used to limit this specification. For those skilled in the art, various changes and modifications can be made to one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of one or more embodiments of this specification shall be included within the scope of the claims of this specification.

Claims

1. A method for cross - environment sharing of Internet of Things service data, characterized in that The method includes: In the export environment node, according to at least one user demand service application of the cross - environment sharing request information triggered by the user, determine the service data FTK package corresponding to the user demand service application, where the service data FTK package includes a summary file and a set of service application models corresponding to the user demand service application; When importing the service data FTK package into multiple import environment nodes in the cross - environment sharing request information, generate a decentralized model code corresponding to each service application model in the service data FTK package, and update the summary file in the service data FTK package with the decentralized model code to determine an updated summary file; Through multiple import environment nodes, verify the received service data FTK package according to the updated summary file. In the import environment nodes where the verification passes, import the set of service application models in the service data FTK package to achieve cross - environment sharing of Internet of Things service data.

2. The cross - environment sharing method for Internet of Things service data according to claim 1, characterized in that, Determine the service data FTK package corresponding to the user demand service application according to at least one user demand service application of the cross - environment sharing request information triggered by the user, specifically including: Extract application features corresponding to multiple service application types to determine a general modeling strategy, where the application types of the user demand service application include any one or more of a data collection service application, a data calculation service application, and a data display service application, and the general modeling strategy includes data items, configuration items, and dependency file items; Based on the user demand service application and the general modeling strategy, perform data retrieval in the export environment node to construct a general service application model corresponding to the user demand service application, where the configuration items in the general service application model are preset values; Obtain the environment - sensitive information corresponding to each import environment node triggered by the user, and through the environment - sensitive information, perform environment - adaptation configuration on the configuration items of the general service application model to determine the service application model corresponding to each user demand service application; Assemble multiple service application models to generate a service data FTK package corresponding to the user demand service application.

3. The cross - environment sharing method for Internet of Things service data according to claim 2, characterized in that, Generate a decentralized model code corresponding to each service application model in the service data FTK package, specifically including: In the export environment node, based on the node environment parameters corresponding to the export environment node, generate a time gene identifier and a node gene identifier corresponding to the export environment node, where the node environment parameters include node clock feature information and node physical feature information; Obtain the model metadata corresponding to each service application model, and perform a hash calculation on the model metadata to determine the data gene identifier corresponding to the service application model; According to a preset encoding method, generate a decentralized model code corresponding to each service application model from the time gene identifier, the node gene identifier, and the data gene identifier; Using the decentralized model code corresponding to each of the business application models as the primary key, perform model registration in the model registry preset in the export environment node, and record the export record corresponding to the business application model.

4. A cross-environment sharing method for Internet of Things service data according to claim 1, characterized in that, Through multiple import environment nodes, verify the business data FTK package received according to the update summary file, specifically including: When the current import environment node receives the business data FTK package, construct an import node channel between the current import environment node and other import environment nodes according to the multiple import environment nodes in the cross-environment sharing request information, where the import node channel automatically disconnects after a preset duration; In the current import environment node, perform environmental node signature on the update summary file of the business data FTK package to generate signature summary information, and perform an inter-transfer operation on the signature summary information with the other import environment nodes through the import node channel; Perform signature verification and summary information consistency verification on the received signature summary information through the current import environment node to determine the number of nodes that pass the verification; When the number of nodes exceeds the preset dynamic node threshold, determine that the verification of the business data FTK package received by the current import environment node passes.

5. A method for cross - environment sharing of Internet of Things service data according to claim 1, characterized in that, In the import environment nodes where the verification passes, import the business application model set in the business data FTK package, specifically including: Retrieve according to the decentralized model code in the update summary file in the local model registry of each import environment node; When the decentralized model code is not retrieved in the local model registry, use the decentralized model code corresponding to the business application model as the primary key to perform model registration in the local model registry, and perform the first import of the corresponding business application model; When the decentralized model code is retrieved in the local model registry, use the decentralized model code as the primary key to determine the corresponding business application model version information in the local model registry; According to the business application model version information, perform version verification in the import environment node to determine the model availability of the business application model, so as to perform an update import of the available model in the import environment node.

6. A method for cross - environment sharing of Internet of Things service data according to claim 5, characterized in that, According to the business application model version information, perform version verification in the import environment node to determine the model availability of the business application model, specifically including: Obtain the local model version information corresponding to the business application model in the local model registry and the environment application deployment version information of the import environment node; Perform dual version verification on the business application model according to the local model version information and the environment application deployment version information to determine the model availability of the business application model.

7. A method for cross - environment sharing of Internet of Things service data according to claim 6, characterized in that, Perform dual version verification on the business application model according to the local model version information and the environment application deployment version information to determine the model availability of the business application model, specifically including: Verify the version information of the business application model based on the version information of the environment application deployment, and determine the application version verification status of the business application model; When the version information of the environment application deployment is not lower than the version information of the business application model, determine that the application version verification status is verified, and verify the version information of the business application model based on the local model version information; When the version information of the business application model is not lower than the version information of the local model, determine that the business application model is an available model.

8. A method for cross - environment sharing of Internet of Things service data according to claim 1, characterized in that, After importing the business application model set in the business data FTK package, the method further includes: When the import environment node modifies a specified business application model in the business application model set, record the modification log corresponding to the specified business application model in the model registry of the import environment node; When receiving an export request for the specified business application model, generate a summary file corresponding to the specified business application model through the modification log.

9. An Internet of Things service data cross - environment sharing device, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method according to any one of claims 1-8.

10. A non-volatile computer storage medium stores computer-executable instructions, characterized in that, The computer-executable instructions are set to: execute the method according to any one of claims 1-8.

Images