A cross-chip cross-platform service application switching method and system

Abstract

The application discloses a cross-chip cross-platform service application switching method and system, and belongs to the field of power system automation. The method comprises the following steps: reading a device configuration file of a target power grid node to obtain a chip type identifier and an operating system type; querying a preset adaptive mapping table according to the two identifiers to determine a corresponding power grid service application version and a dependent component package, wherein the mapping table comprises a mapping relationship among a chip type, an operating system type and a service application version; checking whether a runtime environment of the target power grid node meets installation conditions of the dependent component package; if the installation conditions are met, the power grid service application version and the dependent component package are deployed to the target power grid node, and the power grid service application is started to run, so that the switching of the power grid service application in a cross-chip cross-platform environment is realized. The application realizes the automatic adaptation and seamless switching of the power grid service application in different chip architectures and operating system environments, reduces manual intervention, and improves deployment efficiency.

Description

Technical Field

[0001] This invention relates to the field of power system automation technology, and in particular to a cross-chip, cross-platform business application switching method and system. Background Technology

[0002] With the deepening of the construction of new power systems, power grid business applications are facing an increasingly complex situation of coexistence of heterogeneous hardware and multiple platform operating systems.

[0003] In existing technologies, when cross-chip and cross-platform switching is required due to equipment upgrades, fault replacements, or business migrations, maintenance personnel need to manually identify the target environment, recompile applications, and check dependencies one by one for compatibility. This results in technical problems such as long adaptation cycles, chaotic version management, and difficulty in locating dependency conflicts. In addition, existing solutions lack a joint assessment mechanism for chip architecture compatibility and operating system compatibility, and cannot perform secondary adaptation through compatible instruction sets and kernel versions when precise matching fails. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method and system for switching business applications across chips and platforms.

[0005] This invention provides a cross-chip, cross-platform service application switching method, comprising the following steps: S1. Read the device configuration file of the target power grid node to obtain the chip type identifier and operating system type; S2. Based on the chip type identifier and the operating system type, query the preset adaptation mapping table to determine the corresponding power grid business application version and dependent component package. The adaptation mapping table records the mapping relationship between chip type, operating system type and power grid business application version. S3. Verify whether the runtime environment of the target power grid node meets the installation conditions of the dependent component package. If it does, proceed to S4. If it does not, deploy the dependent component package first. S4. Deploy the power grid service application version and the dependent component package to the target power grid node and start running them to enable the switching of the power grid service application in a cross-chip and cross-platform environment.

[0006] Preferably, in step S1, the target power grid node includes at least one of a substation edge computing node, a distribution area smart terminal, and a master station server.

[0007] Preferably, in step S2, the adaptation mapping table is stored in a two-dimensional hash index structure, wherein the first dimension index is the chip type identifier and the second dimension index is the operating system type; the chip type identifier and the operating system type are used as a joint retrieval key to perform a matching query in the adaptation mapping table.

[0008] Preferably, in step S2, if an exact match is successful, the power grid business application version identifier, application binary package path, dependent component package list, and version compatibility constraint information in the mapping record are directly read.

[0009] Preferably, in step S2, if an exact match fails, a preset chip architecture compatibility matrix and operating system compatibility matrix are queried. The chip architecture compatibility matrix records the correspondence between chip type identifiers and compatible chip architecture instruction sets, and the operating system compatibility matrix records the correspondence between operating system types and compatible operating system kernel versions. Based on the chip type identifier and operating system type of the target power grid node, the corresponding compatible chip architecture instruction sets and compatible operating system kernel versions are retrieved from the chip architecture compatibility matrix and the operating system compatibility matrix, respectively. The compatible chip architecture instruction sets and compatible operating system kernel versions are combined into a joint compatibility retrieval key, and a secondary match is performed in the adaptation mapping table. If the secondary match is successful, the power grid business application version identifier, application binary package path, dependent component package list, and version compatibility constraint information in the mapping record are read, and a compatibility degradation prompt is generated. If the secondary match fails, the current switching process is terminated, and an adaptation failure alarm and an explanation of the incompatibility reason are returned to the dispatch center.

[0010] Preferably, in step S3, the directed acyclic graph of the dependent component packages is traversed, and the installation condition constraints of each dependent component package are extracted item by item. The installation condition constraints include at least one of the following: runtime library version requirements, system kernel parameter thresholds, storage space capacity lower limit, memory resource usage upper limit, and network port usage status. The system monitoring interface of the target power grid node is called to collect the current runtime environment parameters in real time, and the collected environment parameters are compared with the installation condition constraints item by item. If all installation condition constraints are satisfied, an environment verification pass flag is generated, and S4 is executed directly. If there are unsatisfied installation condition constraints, the missing dependent component packages are downloaded and deployed sequentially according to the installation order determined by the directed acyclic graph of the dependent component packages. After each dependent component package is deployed, the dependency relationship of the component package is re-parsed and the directed acyclic graph of the dependent component packages is updated. The environment parameter comparison is performed again until all installation condition constraints are satisfied and there are no new nodes in the directed acyclic graph of the dependent component packages. Then, the deployment status of the dependent component packages is marked as complete, and S4 is executed.

[0011] Preferably, in step S4, based on the instruction set architecture corresponding to the chip type identifier, the instruction set compatibility, file integrity, and digital signature validity of the binary executable file of the power grid business application version are verified. An executable image adapted to the target power grid node chip architecture is generated and loaded into the process address space of the target power grid node. According to the installation order determined by the directed acyclic graph of the dependent component packages, if the deployment completion status of the dependent component packages is not marked, each dependent component package is deployed to the specified runtime directory of the target power grid node. If the deployment completion status of the dependent component packages is marked, the deployed dependent component packages are skipped, and the component service interface is dynamically registered to the system service bus and temporarily not provided to the outside world in a pre-registered state. The running parameters of the power grid business application version are configured. The running parameters include the node communication address, data sampling period, number of business processing threads, and power grid business function switch corresponding to the target power grid node type. After configuration, the status of the component service interface in the system service bus is updated to officially activated. The main process of the power grid business application version is started, a communication link is established with the underlying hardware driver and system service of the target power grid node, a business initialization self-test is performed, and after the self-test is passed, the application is officially connected to the power grid business operating environment, completing the business application switching in a cross-chip and cross-platform environment.

[0012] This invention provides a cross-chip, cross-platform business application switching system, comprising: The configuration reading module is used to read the device configuration file of the target power grid node and obtain the chip type identifier and operating system type; The adaptation query module is used to query a preset adaptation mapping table based on the chip type identifier and the operating system type to determine the corresponding power grid business application version and dependent component package. The adaptation mapping table records the mapping relationship between chip type, operating system type and power grid business application version. The environment verification module is used to verify whether the runtime environment of the target power grid node meets the installation conditions of the dependent component package. If it meets the conditions, the deployment startup module is triggered; otherwise, the dependent component package is deployed first. The deployment and startup module is used to deploy the power grid business application version and the dependent component package to the target power grid node and start it to run, so as to realize the switching of the power grid business application in a cross-chip and cross-platform environment.

[0013] This invention discloses a cross-chip, cross-platform business application switching method and system, which has the following beneficial effects: This invention achieves automated and precise matching of power grid business application versions and dependent component packages by reading the chip type identifier and operating system type of the target power grid node and performing joint retrieval using a two-dimensional hash index structure of a pre-defined adaptation mapping table. This transforms traditional manual adaptation into automatic machine adaptation, significantly shortening the response time for cross-platform switching. The two-dimensional hash index of the adaptation mapping table enables automated joint matching of chip type and operating system type, and a compatibility matrix is ​​introduced for secondary downgrade adaptation, improving the success rate of cross-platform switching. A directed acyclic graph of dependent component packages is used to automatically determine dependency resolution and installation order, combined with runtime environment closed-loop verification to ensure deployment reliability. During the deployment phase, an executable image is generated by verifying instruction set compatibility, file integrity, and digital signature validity. A two-stage mechanism of pre-registration and formal activation of the system service bus, along with differentiated operating parameter configurations, ensures a smooth transition and stable access for business applications during cross-chip and cross-platform switching. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention are provided below.

[0015] Figure 1 The present invention provides a method flowchart for a cross-chip, cross-platform business application switching method. Detailed Implementation

[0016] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention.

[0017] refer to Figure 1 The present invention provides a cross-chip, cross-platform business application switching method, comprising the following steps: S1. Read the device configuration file of the target power grid node to obtain the chip type identifier and operating system type; S2. Based on the chip type identifier and operating system type, query the preset adaptation mapping table to determine the corresponding power grid business application version and dependent component package. The adaptation mapping table records the mapping relationship between chip type, operating system type and power grid business application version. This solution employs a central-edge collaborative layered storage architecture to construct the adaptation mapping table. During initial construction, a multi-target compilation toolchain is configured in the continuous integration environment for core power grid business applications (distribution automation, electricity consumption information collection, master station dispatching and monitoring, etc.) to generate binary products corresponding to different chip architectures and operating system kernel versions. These products are then stored in the database after automated testing and verification. The mapping table uses a three-dimensional hash index of chip type identifier-operating system type-application version. Each record includes a version identifier, binary package path, list of dependent component packages, version compatibility constraints, and a digital signature digest. Metadata of dependent component packages is extracted through a recursive parsing engine to form structured installation condition constraint information (runtime library version, kernel parameter thresholds, storage / memory / port requirements, etc.) and associated with it for storage.

[0018] S3. Verify whether the runtime environment of the target power grid node meets the installation conditions of the dependent component package. If it does, proceed to S4. If it does not, deploy the dependent component package first. S4. Deploy the power grid business application version and dependent component package to the target power grid node and start running it to enable the switching of power grid business applications in a cross-chip and cross-platform environment.

[0019] In a preferred embodiment, in step S1, the target power grid node includes at least one of a substation edge computing node, a distribution substation smart terminal, and a master station server.

[0020] In a preferred embodiment, step S2 specifically includes the following steps: S21. Use the chip type identifier and operating system type as the joint search key to perform a matching query in the preset adaptation mapping table. The adaptation mapping table is stored in a two-dimensional hash index structure, where the first dimension index is the chip type identifier and the second dimension index is the operating system type. S22. If an exact match is successful, directly read the power grid business application version identifier, application binary package path, dependent component package list and version compatibility constraint information from the mapping record. S23. If an exact match fails, the preset chip architecture compatibility matrix and operating system compatibility matrix are queried. The chip architecture compatibility matrix records the correspondence between chip type identifiers and compatible chip architecture instruction sets, and the operating system compatibility matrix records the correspondence between operating system types and compatible operating system kernel versions. Based on the chip type identifier and operating system type of the target power grid node, the corresponding compatible chip architecture instruction sets and compatible operating system kernel versions are retrieved from the chip architecture compatibility matrix and operating system compatibility matrix, respectively. The compatible chip architecture instruction sets and compatible operating system kernel versions are combined into a joint compatibility retrieval key, and a secondary match is performed in the adaptation mapping table. If the secondary match is successful, the power grid business application version identifier, application binary package path, dependent component package list, and version compatibility constraint information in the mapping record are read, and a compatibility degradation prompt is generated. If the secondary match fails, the current switching process is terminated, and an adaptation failure alarm and an explanation of the incompatibility reason are returned to the dispatch center. The chip architecture compatibility matrix is ​​constructed based on the following: Instruction set hierarchy analysis: The instruction set architecture corresponding to each chip type is decomposed into basic instruction set, extended instruction set, and privileged instruction set. By comparing the instruction coverage relationship between the target chip and candidate compatible chips at each level, the compatibility level is determined. Fully compatible: The target chip's basic instruction set, extended instruction set, and privileged instruction set all cover the candidate chip's instructions; Partial compatibility: The target chip's basic instruction set covers the candidate chip, but there are missing extended instruction sets or privileged instruction sets, which need to be compensated for through software simulation or downgrade processing; Incompatibility: The basic instruction set contains instructions that are not covered and cannot be compensated for by software.

[0021] Matrix storage structure: The chip architecture compatibility matrix adopts sparse matrix storage. The rows represent the target chip type identifier, the columns represent the compatible chip architecture instruction set, and the matrix element values ​​are the compatibility level identifier and the degradation processing strategy identifier.

[0022] The operating system compatibility matrix is ​​constructed based on the following: Kernel interface compatibility analysis: Extract the system call table, dynamic link library version, and kernel configuration parameter space corresponding to the kernel version of each operating system type, and determine compatibility through interface signature comparison. Interface matching is complete: the system call table of the target operating system kernel version covers all system calls of the candidate operating system kernel version, and the major version numbers of the dynamic link libraries are consistent; Interface backward compatibility: The system call table of the target operating system kernel version covers a core subset of the candidate version, and missing interfaces can be simulated through the user-space compatibility layer; Interface incompatibility: Core system calls are missing and cannot be simulated in user space.

[0023] Matrix storage structure: The operating system compatibility matrix also adopts sparse matrix storage. The rows represent the target operating system type, the columns represent the compatible operating system kernel version, and the matrix element values ​​are the compatibility level identifier and the compatibility level simulation strategy identifier.

[0024] Execution logic of quadratic matching When an exact match fails, the execution logic for a secondary match is as follows: Step 1: Search for compatible chip architecture instruction sets and compatible operating system kernel versions respectively. Using the chip type identifier of the target power grid node as the search key, query the chip architecture compatibility matrix for all chip architecture instruction sets with a compatibility level of "fully compatible" or "partially compatible" to form a candidate chip architecture instruction set set; using the operating system type of the target power grid node as the search key, query the operating system compatibility matrix for all compatible operating system kernel versions with a compatibility level of "interface fully matched" or "interface forward compatible" to form a candidate operating system kernel version set.

[0025] Step 2: Combine compatible search keys The candidate chip architecture instruction set and the candidate operating system kernel version set are combined using a Cartesian product to generate a joint compatibility search key set. These keys are then sorted by compatibility level priority and used sequentially for matching queries in the adaptation mapping table.

[0026] Step 3: Generate compatibility downgrade prompt If the secondary matching is successful, a compatibility degradation suggestion is generated based on the compatibility level differences between the actual matched chip architecture instruction set and operating system kernel version and the original chip type identifier and operating system type of the target node. The degradation suggestion should include at least: degradation type, scope of degradation impact (e.g., performance impact / functional limitation / need to enable compatibility layer), and recommended optimization measures (e.g., recommending upgrading the hardware platform or operating system version).

[0027] S24. Based on the list of dependent component packages, recursively parse the version dependencies of each dependent component package, construct a complete directed acyclic graph of dependent component packages, and determine all dependent component packages required for the operation of the power grid business application version and their installation order.

[0028] In a preferred embodiment, step S3 specifically includes the following steps: S31. Traverse the directed acyclic graph of dependent component packages and extract the installation condition constraints of each dependent component package one by one. The installation condition constraints include at least one of the following: runtime library version requirements, system kernel parameter thresholds, storage space capacity lower limit, memory resource usage upper limit, and network port usage status. S32. Call the system monitoring interface of the target power grid node to collect the current running environment parameters in real time, and compare the collected environment parameters with the installation condition constraints item by item. S33. If all installation conditions are met, generate an environment verification pass flag and proceed directly to S4. S34. If there are unmet installation constraints, download and deploy the missing dependent component packages in sequence according to the installation order determined by the directed acyclic graph of the dependent component packages. After each dependent component package is deployed, re-parse the dependency relationship of the component package and update the directed acyclic graph of the dependent component packages. Re-execute S32 to compare environment parameters until all installation constraints are met and there are no new nodes in the directed acyclic graph of the dependent component packages. Then mark the deployment status of the dependent component packages as complete and execute S4.

[0029] In a preferred embodiment, step S4 specifically includes the following steps: S41. Based on the instruction set architecture corresponding to the chip type identifier, verify the instruction set compatibility, file integrity, and digital signature validity of the binary executable file of the power grid business application version, generate an executable image adapted to the chip architecture of the target power grid node, and load it into the process address space of the target power grid node. S42. According to the installation order determined by the directed acyclic graph of the dependent component packages, if the deployment completion status of the dependent component packages is not marked, each dependent component package is deployed to the specified runtime directory of the target power grid node. If the deployment completion status of the dependent component packages is marked, the deployed dependent component packages are skipped, and the component service interface is dynamically registered to the system service bus and temporarily not provided to the outside world in a pre-registered state. S43. Configure the operating parameters of the power grid business application version. The operating parameters include the node communication address, data sampling period, number of business processing threads, and power grid business function switch corresponding to the target power grid node type. After configuration, update the component service interface status in the system service bus to be officially activated. S44. Start the main process of the power grid business application version, establish a communication link with the underlying hardware driver and system service of the target power grid node, perform a business initialization self-test, and after the self-test passes, officially connect to the power grid business operation environment to complete the business application switching in a cross-chip and cross-platform environment.

[0030] For example, taking a 220kV substation intelligent transformation project as an example, the original line protection and control application of the substation ran on an edge computing node with an ARM Cortex-A72 architecture and an embedded Linux operating system. Now, due to the expansion and upgrade of the main equipment, it is necessary to switch the application to a newly deployed x86_64 architecture industrial control computer with the operating system Kylin V10.

[0031] During the switchover, the device configuration file of the new edge computing node is first read to obtain the chip type identifier "x86_64" and the operating system type "Kylin-V10" (S1). The scheduling center uses the above identifiers as a joint search key to perform an exact match in the preset adaptation mapping table, hitting the protection and control business application version V2.1 corresponding to the node type, the application binary package path, and the list of dependent component packages including the real-time database component, IEC61850 communication middleware, and security encryption module; at the same time, the version dependencies of each component are recursively parsed to construct a directed acyclic graph of dependent component packages, and the installation order is determined to be security encryption module → real-time database → communication middleware.

[0032] By collecting runtime environment parameters of the new node through the system monitoring interface, it was found that the glibc version required by the real-time database was lower than the dependency constraint, and that storage space, memory, and network ports met the requirements. Following the direction acyclic graph order, the system first downloaded and deployed a compatible glibc patch package, updated the environment, and then re-verified it successfully.

[0033] The system verifies the x86_64 instruction set compatibility, SHA-256 file integrity, and digital signature validity of the V2.1 version binary file, generates an executable image, and loads it into the process address space. It deploys each component to the specified runtime directory according to the dependency graph order, dynamically registers the component service interfaces to the system service bus, and sets them to a pre-registered state. It configures the node communication address to the substation process layer GOOSE network segment, the data sampling period to 80 points per cycle, and the number of business processing threads to 4 cores and 8 threads. After activating the service bus interface, it starts the main process, completes the initialization self-test of the communication link with the underlying hardware driver and GOOSE / SV, and formally connects to the substation business operation environment, achieving seamless switching of protection and control services across ARM to x86 chips and Linux to Kylin platforms.

[0034] This invention provides a cross-chip, cross-platform business application switching system, comprising: The configuration reading module is used to read the device configuration file of the target power grid node and obtain the chip type identifier and operating system type; The adaptation query module is used to query a preset adaptation mapping table based on the chip type identifier and the operating system type to determine the corresponding power grid business application version and dependent component package. The adaptation mapping table records the mapping relationship between chip type, operating system type and power grid business application version. The environment verification module is used to verify whether the runtime environment of the target power grid node meets the installation conditions of the dependent component package. If it meets the conditions, the deployment startup module is triggered; otherwise, the dependent component package is deployed first. The deployment and startup module is used to deploy the power grid business application version and the dependent component package to the target power grid node and start it to run, so as to realize the switching of the power grid business application in a cross-chip and cross-platform environment.

Claims

1. A method for switching business applications across chips and platforms, characterized in that, The steps include the following: S1. Read the device configuration file of the target power grid node to obtain the chip type identifier and operating system type; S2. Based on the chip type identifier and the operating system type, query the preset adaptation mapping table to determine the corresponding power grid business application version and dependent component package. The adaptation mapping table records the mapping relationship between chip type, operating system type and power grid business application version. S3. Verify whether the runtime environment of the target power grid node meets the installation conditions of the dependent component package. If it does, proceed to S4. If it does not, deploy the dependent component package first. S4. Deploy the power grid service application version and the dependent component package to the target power grid node and start running them to enable the switching of the power grid service application in a cross-chip and cross-platform environment.

2. The cross-chip, cross-platform service application switching method according to claim 1, characterized in that, In step S1, the target power grid node includes at least one of a substation edge computing node, a distribution area smart terminal, and a master station server.

3. The cross-chip, cross-platform service application switching method according to claim 1, characterized in that, In step S2, the adaptation mapping table is stored in a two-dimensional hash index structure, where the first dimension index is the chip type identifier and the second dimension index is the operating system type; the chip type identifier and the operating system type are used as a joint retrieval key to perform a matching query in the adaptation mapping table.

4. The cross-chip, cross-platform business application switching method according to claim 3, characterized in that, In step S2, if an exact match is successful, the power grid business application version identifier, application binary package path, dependent component package list, and version compatibility constraint information in the mapping record are directly read.

5. The cross-chip, cross-platform service application switching method according to claim 3, characterized in that, In step S2, if an exact match fails, a preset chip architecture compatibility matrix and operating system compatibility matrix are queried. The chip architecture compatibility matrix records the correspondence between chip type identifiers and compatible chip architecture instruction sets, and the operating system compatibility matrix records the correspondence between operating system types and compatible operating system kernel versions. Based on the chip type identifier and operating system type of the target power grid node, the corresponding compatible chip architecture instruction set and compatible operating system kernel version are retrieved from the chip architecture compatibility matrix and the operating system compatibility matrix, respectively. The compatible chip architecture instruction set and the compatible operating system kernel version are combined into a joint compatibility retrieval key, and a secondary match is performed in the adaptation mapping table. If the secondary match is successful, the power grid business application version identifier, application binary package path, dependent component package list, and version compatibility constraint information in the mapping record are read, and a compatibility downgrade prompt is generated. If the second matching fails, the current switching process will be terminated, and an adaptation failure alarm and an explanation of the incompatibility reason will be returned to the scheduling center.

6. The cross-chip, cross-platform service application switching method according to claim 1, characterized in that, In step S3, the directed acyclic graph of the dependent component packages is traversed, and the installation condition constraints of each dependent component package are extracted item by item. The installation condition constraints include at least one of the following: runtime library version requirements, system kernel parameter thresholds, storage space capacity lower limit, memory resource usage upper limit, and network port usage status. The system monitoring interface of the target power grid node is invoked to collect the current runtime environment parameters in real time. The collected environment parameters are compared with the installation condition constraints item by item. If all installation condition constraints are met, an environment verification pass flag is generated, and S4 is executed directly. If there are unmet installation condition constraints, the missing dependency component packages are downloaded and deployed sequentially according to the installation order determined by the directed acyclic graph of the dependency component packages. After each dependency component package is deployed, the dependency relationship of the component package is re-parsed and the directed acyclic graph of the dependency component packages is updated. The environment parameter comparison is performed again until all installation condition constraints are met and there are no new nodes in the directed acyclic graph of the dependency component packages. Then, the dependency component package deployment status is marked as complete, and S4 is executed.

7. The cross-chip, cross-platform service application switching method according to claim 1, characterized in that, In step S4, based on the instruction set architecture corresponding to the chip type identifier, the instruction set compatibility, file integrity, and digital signature validity of the binary executable file of the power grid business application version are verified. An executable image adapted to the target power grid node chip architecture is generated and loaded into the process address space of the target power grid node. According to the installation order determined by the directed acyclic graph of the dependent component packages, if the deployment completion status of the dependent component packages is not marked, each dependent component package is deployed to the specified runtime directory of the target power grid node. If the deployment completion status of the dependent component packages is marked, the deployed dependent component packages are skipped, and the component service interface is dynamically registered to the system service bus and temporarily not provided to the outside world in a pre-registered state. The running parameters of the power grid business application version are configured. The running parameters include the node communication address, data sampling period, number of business processing threads, and power grid business function switch corresponding to the target power grid node type. After the configuration is completed, the status of the component service interface in the system service bus is updated to officially activated. The main process of the power grid business application version is started, a communication link is established with the underlying hardware driver and system service of the target power grid node, a business initialization self-test is performed, and after the self-test is passed, the application is officially connected to the power grid business operating environment, completing the business application switching in a cross-chip and cross-platform environment.

8. A cross-chip, cross-platform business application switching system, characterized in that, include: The configuration reading module is used to read the device configuration file of the target power grid node and obtain the chip type identifier and operating system type; The adaptation query module is used to query a preset adaptation mapping table based on the chip type identifier and the operating system type to determine the corresponding power grid business application version and dependent component package. The adaptation mapping table records the mapping relationship between chip type, operating system type and power grid business application version. The environment verification module is used to verify whether the runtime environment of the target power grid node meets the installation conditions of the dependent component package. If it meets the conditions, the deployment startup module is triggered; otherwise, the dependent component package is deployed first. The deployment and startup module is used to deploy the power grid business application version and the dependent component package to the target power grid node and start it to run, so as to realize the switching of the power grid business application in a cross-chip and cross-platform environment.

Images