Method and system for lifecycle management of heterogeneous functional components

Abstract

The application discloses a kind of life cycle management methods and systems of heterogeneous functional components, and the application relates to the technical field of life cycle management, multiple function packages are loaded to corresponding multi-source management space, and multiple subspace sources are marked in the multi-source management space, the priority of each subspace source is sorted, and the corresponding download event is determined by cross matching of each function package;Multiple subspace sources include local cache source, enterprise private source and official public source, improve the accuracy of download event.According to the corresponding conflict resolution means determined by the conflict content and the corresponding constraint relationship, the target framework is determined in combination with the corresponding framework compatibility, and the load of the corresponding heterogeneous functional component is marked to optimize the occupation of the corresponding memory, and the life cycle management of heterogeneous functional components is triggered by combining the state tracking mechanism of each function package, which improves the life cycle management effect of heterogeneous functional components.

Description

Technical Field

[0001] This invention relates to the technical field of lifecycle management, and in particular to a lifecycle management method and system for heterogeneous functional components. Background Technology

[0002] In the field of modern industrial automation software, as system functions become increasingly complex, software architecture is gradually evolving towards modularity and service-orientation. This typically requires the integration of various heterogeneous functional components such as vision methods, motion control, and communication protocols. In existing technologies, heterogeneous functional components often lack a unified encapsulation protocol, and the metadata descriptions of components (such as dependencies and version information) vary in format. Traditional software architectures usually rely on a single file storage or network repository for loading. Because local cache sources, enterprise private sources, and official public sources are not hierarchically marked and prioritized, the system cannot automatically plan the optimal download event based on network load, security, and availability, which affects the accuracy of download events and cannot guarantee the lifecycle management effect of heterogeneous functional components. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a lifecycle management method and system for heterogeneous functional components.

[0004] This invention provides a lifecycle management method for heterogeneous functional components, including:

[0005] Based on the detection of the component database, the corresponding component protocol is determined, and multiple heterogeneous functional components are encapsulated along the component protocol to output the corresponding function package. Each function package contains a nuspec metadata description file.

[0006] Multiple function packages are loaded into the corresponding multi-source management space, and multiple sub-sources are marked in the multi-source management space. The priority of each sub-source is sorted, and the corresponding download event is determined by cross-matching of each function package. The multiple sub-sources include local cache sources, enterprise private sources, and official public sources.

[0007] In this download event, the corresponding dependency tree is marked, and the conflict content is determined in the dependency tree detection. Based on the conflict content and the corresponding constraint relationship, the corresponding conflict resolution method is determined. The target framework is determined in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts.

[0008] The loading process of each function package is monitored in real time, and the load of the corresponding heterogeneous function components is marked to optimize the memory usage. Combined with the state tracking mechanism of each function package, the lifecycle management of heterogeneous function components is triggered, and online protection is provided for heterogeneous function components that are in use.

[0009] This invention provides a lifecycle management system for heterogeneous functional components, which is applied to the aforementioned lifecycle management method for heterogeneous functional components; the lifecycle management system for heterogeneous functional components includes:

[0010] The function package module is used to determine the corresponding component protocol based on the detection of the component database, trigger the encapsulation of multiple heterogeneous functional components along the component protocol, and output the corresponding function package. Each function package contains a nuspec metadata description file.

[0011] The download event module is used to load multiple function packages into the corresponding multi-source management space, mark multiple sub-space sources in the multi-source management space, sort the priority of each sub-space source, and determine the corresponding download event by combining the cross-matching of each function package; the multiple sub-space sources include local cache sources, enterprise private sources and official public sources;

[0012] The conflict management module is used to mark the corresponding dependency tree in the download event, determine the conflict content in the dependency tree detection, determine the corresponding conflict resolution method based on the conflict content and the corresponding constraint relationship, and determine the target framework in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts.

[0013] The lifecycle management module is used to monitor the loading process of each function package in real time and mark the load of the corresponding heterogeneous function components in order to optimize the memory usage. Combined with the state tracking mechanism of each function package, it triggers the lifecycle management of heterogeneous function components and provides online protection for heterogeneous function components that are in use.

[0014] Compared with the prior art, the beneficial effects of the present invention are:

[0015] (1) Based on the detection of the component database, the corresponding component protocol is determined, and multiple heterogeneous functional components are encapsulated along the component protocol to output the corresponding functional package. Each functional package contains a nuspec metadata description file. Multiple functional packages are loaded into the corresponding multi-source management space, and multiple sub-space sources are marked in the multi-source management space. The priority of each sub-space source is sorted, and the corresponding download event is determined by combining the cross-matching of each functional package. Multiple sub-space sources include local cache sources, enterprise private sources and official public sources. Multiple functional packages are introduced. Multiple functional packages are managed in the multi-source management space, which improves the accuracy of download events.

[0016] (2) In the download event, the corresponding dependency tree is marked, and the conflict content is determined in the dependency tree detection. The conflict resolution method is determined according to the conflict content and the corresponding constraint relationship. The target framework is determined in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts. The loading process of each function package is monitored in real time, and the load of the corresponding heterogeneous function components is marked to optimize the corresponding memory usage. The life cycle management of heterogeneous function components is triggered in combination with the state tracking mechanism of each function package. The overall consideration of conflict resolution method and framework compatibility is realized, the accuracy of the target framework is improved, and the memory usage is optimized synchronously, which improves the life cycle management effect of heterogeneous function components and provides online protection for heterogeneous function components in use. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the lifecycle management method for heterogeneous functional components in an embodiment of the present invention.

[0018] Figure 2 This is a flowchart illustrating step S11 in the lifecycle management method for heterogeneous functional components in this embodiment of the invention.

[0019] Figure 3 This is a flowchart illustrating step S12 in the lifecycle management method for heterogeneous functional components in this embodiment of the invention.

[0020] Figure 4 This is a flowchart illustrating step S13 in the lifecycle management method for heterogeneous functional components in this embodiment of the invention.

[0021] Figure 5 This is a flowchart illustrating step S14 in the lifecycle management method for heterogeneous functional components in this embodiment of the invention.

[0022] Figure 6 This is a schematic diagram of the structural composition of the lifecycle management system for heterogeneous functional components in an embodiment of the present invention. Detailed Implementation

[0023] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0024] Please see Figures 1 to 6 A lifecycle management method for heterogeneous functional components, applied to lifecycle management scenarios; the lifecycle management method for heterogeneous functional components includes:

[0025] Step S11: Determine the corresponding component protocol based on the detection of the component database, trigger the encapsulation of multiple heterogeneous functional components along the component protocol, and output the corresponding functional package. Each functional package contains a nuspec metadata description file.

[0026] Step S12: Load multiple function packages into the corresponding multi-source management space, mark multiple sub-space sources in the multi-source management space, sort the priority of each sub-space source, and determine the corresponding download event by combining the cross-matching of each function package; the multiple sub-space sources include local cache sources, enterprise private sources and official public sources;

[0027] Step S13: In this download event, mark the corresponding dependency tree, determine the conflict content in the dependency tree detection, determine the corresponding conflict resolution method according to the conflict content and the corresponding constraint relationship, and determine the target framework in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts.

[0028] Step S14: Monitor the loading process of each function package in real time and mark the load of the corresponding heterogeneous function components to optimize the corresponding memory usage. Combine the state tracking mechanism of each function package to trigger the lifecycle management of heterogeneous function components and provide online protection for heterogeneous function components in use.

[0029] refer to Figure 2 In step S11, the specific steps are as follows:

[0030] S111: Collect the component database, detect the component database, determine the corresponding protocol information during the detection process, determine the corresponding component protocol by tracing the protocol information, and determine the multi-dimensional protocol structure based on the parsing of the component protocol.

[0031] S112: Determine the corresponding encapsulation route based on the detection of the multidimensional protocol structure, trigger the encapsulation of multiple heterogeneous functional components based on the encapsulation route, and determine the corresponding functional package; in each functional package, each functional package contains a nuspec metadata description file, and determine the identification information, dependency tree, and component type identifier of the functional package based on the parsing of the nuspec metadata description file.

[0032] In the embodiments of this application, a component database is collected, the component database is detected, and the corresponding protocol information is determined during the detection process. The corresponding component protocol is determined by tracing the protocol information. In the component protocol, a multi-dimensional protocol structure is determined based on the parsing of the component protocol, which is compatible with the overall consideration of the parsing of the component protocol and ensures the accuracy of the multi-dimensional protocol structure.

[0033] At this point, the system performs a full scan of the underlying storage medium and collects the corresponding component database during the scan. The component database is not a single relational table, but a composite repository containing source code metadata, configuration manifests, and historical version records. During the collection of the component database, the collection process extracts the raw data of the component through data access interfaces (such as ADO.NET or ORM frameworks). The raw data includes the component's physical storage path, compilation target architecture, and preliminary descriptive information associated with the component, providing raw data input for subsequent protocol matching.

[0034] The system performs feature recognition on the collected raw data. The core of the recognition lies in identifying the technical information of the components, such as the component's file extension, the runtime environment identifier it depends on, or specific manifest file characteristics. Based on these characteristics, the system then determines which protocol specification the component should follow.

[0035] The system loads specific component protocols from a pre-built protocol library by indexing protocol information. Protocol information is merely an index key, while component protocols are a complete set of constraints. The system retrieves the complete schema definition that the component must adhere to through a reverse tracing mechanism. The complete schema definition includes interface contracts, lifecycle hook function signatures, and standard formats for interacting with other components. This process ensures that all subsequently generated function packages maintain consistency in their underlying logic and conform to the platform's unified scheduling standards.

[0036] The system performs in-depth analysis of the loaded component protocols, breaking them down into a multi-dimensional protocol structure to guide the subsequent encapsulation process. This multi-dimensional protocol structure typically includes an identification dimension, a dependency dimension, a behavior dimension, and a physical dimension. The identification dimension defines the unique identification encoding rules for the component; the dependency dimension defines the dependency constraint format of the component on external libraries and the runtime environment; the behavior dimension defines the component's input / output interface specifications and execution context requirements at runtime; and the physical dimension defines the physical storage structure and directory hierarchy specifications of the component files.

[0037] Specifically, we are processing a heterogeneous functional component called "high-precision visual positioning method". The system scans the component database and extracts the original records of the visual method component, including the path of its compiled DLL file, the associated OpenCV library version information, and preliminary functional description text.

[0038] The system detects that the component references the OpenCV image processing library and contains standard method interfaces (such as IAlgorithmProcess), thereby identifying the image processing characteristics of the component and marking its protocol information as "Algorithm-Type". Based on the "Algorithm-Type" mark, the system traces and loads the predefined "Industrial Vision Method Component Protocol".

[0039] The system parses the industrial vision component protocol and generates a multi-dimensional structure: the identification dimension defines that its ID must conform to the format Com.Vision.{AlgorithmName}; the dependency dimension stipulates that the dependency scope of OpenCV 4.0 and above must be declared in the metadata; the behavior dimension stipulates that the input must be an image data stream object and the output must include the result status code; the physical dimension stipulates that the dynamic library must be stored in the lib / net6.0 directory.

[0040] Furthermore, based on the detection of this multidimensional protocol structure, the corresponding encapsulation route is determined, and the encapsulation of multiple heterogeneous functional components is triggered according to the encapsulation route, and the corresponding functional package is determined. In each functional package, each functional package contains a nuspec metadata description file. Based on the parsing of the nuspec metadata description file, the identification information, dependency tree, and component type identifier of the functional package are determined, which is compatible with the overall consideration of the detection of multidimensional protocol structure and ensures the accuracy of the corresponding encapsulation route.

[0041] At this point, the system performs in-depth detection on the multi-dimensional protocol structure output by step S111, focusing on analyzing the "physical dimension" and "identification dimension" in the protocol. Based on the target operating framework, CPU architecture (such as x64 or ARM) and component type defined in the protocol, the system dynamically generates a packaged execution chain. This packaged execution chain defines the specific processes of file copying, directory construction, metadata injection, and post-compilation processing. The detection process is essentially mapping abstract protocol constraints into a specific sequence of file system operation instructions.

[0042] The packaging engine automatically performs packaging operations for heterogeneous functional components according to the determined packaging execution chain; the system extracts the compiled binary files, dependency libraries and resource files from the component database and physically organizes them according to the directory structure predefined by the packaging route; during this process, the system also performs digital signature verification and integrity checks on the components, and finally gathers the scattered files into a standardized "functional package". This functional package is a self-contained logical unit with the ability to be independently released and deployed.

[0043] Each generated feature package automatically produces a Nuspec metadata description file in its root directory; the system parses this file and extracts key identifier fields, including reading... <id>The field is used to obtain a globally unique identifier that conforms to the reverse domain name specification. <version>The field confirms the semantic version number, and reads... <authors>and <description>The fields confirm copyright and function descriptions; the parsing process converts XML-formatted text data into a system-recognizable identifier object, establishing the component's identity index in the platform registry.

[0044] The system continues to perform in-depth analysis of the nuspec file. <dependencies>Nodes and <metadata>Type tags, by parsing dependency groups, allow the system to construct a complete dependency tree for the function package, clarifying the external libraries required for the component to run and their version range constraints; at the same time, the system identifies custom metadata tags to determine whether the component belongs to the driver, method, logic or UI type. This step is the data foundation for subsequent dependency resolution and conflict arbitration.

[0045] Specifically, the system detected that in the multi-dimensional protocol structure generated by S111, the "physical dimension" explicitly specified the target framework as .NET 6.0 and the component nature as a pure method library; based on this, the system determined the encapsulation route as: "create the lib / net6.0 directory structure, exclude any GAC registration operations of unmanaged DLLs, and enable the lightweight packaging template dedicated to method components."

[0046] When the encapsulation engine is triggered, it copies the VisionLocation.dll generated by compiling the "High Precision Vision Positioning Method" and its dependent OpenCV runtime library to the lib / net6.0 directory. At the same time, it saves the calibration parameter template files required by the method into the content directory. These files are packaged and compressed to generate a function package named HighPrecisionVision.1.0.0.nupkg.

[0047] The system decompresses and reads the HighPrecisionVision.nuspec file within the package; after parsing the XML nodes, it confirms their identification information: <id> Com.Vision.HighPrecision< / id> The version number is 1.0.0, and the author is VisionLab; the system enters this information into the component registration center to complete the identity verification.

[0048] The system continued parsing the nuspec file and found... <dependencies>The node records dependencies on external libraries: OpenCV (≥4.5.0) and Newtonsoft.Json (≥13.0.1), thus constructing the dependency tree for this component; simultaneously, it detects in the metadata... <tags> AlgorithmVision< / tags> The system uses this tag to determine that the type of the function package is "Algorithm" (method type), preparing it for registration with the method node manager at runtime.

[0049] refer to Figure 3 In step S12, the specific steps are as follows:

[0050] S121: Collect the preset multi-source management space, load multiple function packages into the same multi-source management space along different channels, each function package is controlled in different dimensions in the multi-source management space, and outputs the corresponding subspace source along the corresponding dimension control path to mark multiple subspace sources;

[0051] S122: Mark the priority of multiple subspace sources, perform cross-matching based on the status of each function package and the load of the multi-source management space, and mark the corresponding comparison results in turn during the cross-matching process. Perform multi-level iteration on multiple comparison results, and determine multiple download elements during the iteration process. Perform multi-factor fusion based on multiple download elements to construct the corresponding download event. The multiple subspace sources cover local cache sources, enterprise private sources and official public sources. Local cache sources, enterprise private sources and official public sources all have corresponding control logic.

[0052] In the embodiments of this application, a preset multi-source management space is collected, and multiple function packages are loaded into the same multi-source management space along different channels. Each function package is controlled in different dimensions in the multi-source management space, and the corresponding subspace source is output along the corresponding dimension control path to mark multiple subspace sources, thus introducing the concept of marking multiple subspace sources.

[0053] At this point, the system initializes and loads the pre-configured repository context environment. The multi-source management space is not a single physical storage, but a logical abstraction layer that aggregates multiple physically isolated or network-isolated storage media. The system reads the configuration file (such as NuGet.Config), collects the access credentials, network proxy settings and security policies of the space, and builds a unified resource access context. This process provides a secure and compliant operating environment for subsequent function package loading.

[0054] The system selects different transmission channels for loading based on the source attributes and network location of the function packages. For locally generated packages, the system directly mounts them using file system I / O stream channels. For enterprise intranet packages, the system uses protected internal network channels (such as HTTP / HTTPS protocols). For public Internet packages, the system uses public network channels combined with authentication mechanisms. Despite the different transmission channels, all function packages are ultimately logically mapped to the same multi-source management space, achieving decoupling between physical distribution and logical unity.

[0055] Once in the management space, the system implements multi-dimensional metadata control for each functional package. These dimensions include security, version, and visibility. Security involves verifying the package's digital signature and integrity hash value to prevent tampering. Versioning records the package's semantic version number, constructing a version evolution graph. Visibility is determined by marking the package's visibility scope based on its origin (e.g., locally only, enterprise-wide, or publicly visible). This process ensures that every package entering the management space is under control, providing reliable data support for subsequent scheduling.

[0056] Based on the control results, the system distributes the logical index of the function package to specific subspace source nodes. The system automatically constructs and marks three core subspace sources: local cache source, enterprise private source, and official public source. Local cache source: stores downloaded packages that have passed integrity verification and is marked as the highest priority. Enterprise private source: indexes packages on the enterprise's internal servers and is marked as the second highest priority. Official public source: indexes resources from public repositories (such as nuget.org) and is marked as the lowest priority. The system introduces a source mapping table, which clearly records the existence status of each function package in different subspace sources.

[0057] Specifically, the system is processing a heterogeneous functional component called "high-precision visual positioning method". The system starts the warehouse service, reads the policy of the factory configuration center, loads the "industrial vision component management space", which is configured to enforce TLS1.2 encrypted transmission and enable enterprise-level identity authentication.

[0058] The "High-Precision Visual Positioning Method" package (HighPrecisionVision.1.0.0.nupkg) is a newly packaged component that is directly mounted to the management space through the local file system channel. At the same time, the system detects that the package depends on the OpenCV library, and thus triggers the external loading mechanism to query the index information of the dependent package from the private server through the enterprise intranet HTTP channel.

[0059] Within the management space, the system controls the "High-Precision Visual Positioning Method" package: Security dimension: The system verifies whether the accompanying digital certificate is issued by the trusted "Visual Method Lab"; Version dimension: The system confirms that its version 1.0.0 is lower than the 1.0.1-beta already existing in the private source, and marks it as "Stable Version"; Status dimension: Since this package is uploaded for the first time, the system marks it as "Pending Release".

[0060] After the control is completed, the system outputs subspace source tags according to the path rules: Since the package is directly mounted as a local file, the system writes its index to the local cache source and marks it as "highest priority" to ensure that this version is used first during subsequent local debugging; at the same time, the system sends a registration request to the enterprise private source to generate a pre-release index of the package and marks it as "second highest priority" for other team members to test; at this time, the official public source does not yet have the index of the package, and the system marks the package as "not present" in the subspace source.

[0061] Furthermore, the priorities of multiple subspace sources are marked, and cross-matching is performed based on the status of each function package and the load of the multi-source management space. During the cross-matching process, the corresponding comparison results are marked sequentially, and multiple comparison results are iterated at multiple levels. During the iteration process, multiple download elements are determined, and multi-factor fusion is performed based on multiple download elements to construct the corresponding download event. The multiple subspace sources cover local cache sources, enterprise private sources, and official public sources. Each of the local cache sources, enterprise private sources, and official public sources has corresponding control logic, which is compatible with the overall consideration of multi-factor fusion of multiple download elements and ensures the corresponding download event. The accuracy of the multiple subspace sources covering local cache sources, enterprise private sources, and official public sources is ensured. At the same time, multiple function packages are introduced, and multiple function packages are managed in the multi-source management space, which improves the accuracy of download events.

[0062] At this point, the system assigns priority values ​​to the subspace sources output in step S121 according to the preset configuration strategy. In industrial automation scenarios, to ensure system controllability and response speed, a strict priority reduction strategy is usually adopted to sort the priorities of multiple subspace sources: local cache sources are marked as the highest priority (Priority=0), enterprise private sources are next (Priority=1), and official public sources have the lowest priority (Priority=2). The system stores this priority weight in the packet management context as the basis for subsequent scheduling methods.

[0063] The system constructs a multi-dimensional matching matrix. The horizontal dimension represents the current status of the function package (e.g., "installed", "pending update", "not installed"), and the vertical dimension represents the load status of each subspace source (e.g., "idle", "busy", "offline"). The system executes cross-matching logic, which checks whether a copy of the function package already exists locally, and simultaneously detects the network latency and concurrent connection count of each subspace source. The matching process aims to filter out a set of available sources that contain both the target resource and the service capability.

[0064] Based on the matching matrix, the system initiates a multi-level iterative comparison process: Level 1 iteration (validity comparison): compare whether each source contains a valid version of the target packet, eliminate invalid sources, and mark the result as "valid" or "invalid"; Level 2 iteration (timeliness comparison): compare the consistency between each source version and the target version, and prioritize marking sources that match completely; Level 3 iteration (performance comparison): compare the response latency and bandwidth load of valid sources; the system marks the comparison results of each level of iteration and passes them to the next level, gradually narrowing down the range of optimal candidate sources.

[0065] After the iteration, the system extracts key download elements from the candidate source set, including: target source address, authentication token, data verification hash value, and estimated transmission time. The system uses a weighted scoring method to integrate multiple factors and calculates the source with the highest comprehensive score as the final executor. The system generates a standardized "download event" object, which encapsulates all the context information and execution instructions required for the download action, waiting for the scheduler to trigger it.

[0066] Specifically, the system reads the factory configuration strategy and assigns weights to the three subspace sources associated with the "high-precision visual positioning method": the local cache source is marked as Priority=High (highest priority, designed to utilize local high-speed IO); the enterprise private source is marked as Priority=Medium (medium priority, used for team collaboration and synchronization); and the official public source is marked as Priority=Low (lowest priority, as a fallback solution for external dependencies).

[0067] The system detected that the "High-Precision Visual Positioning Method" function package is currently "Not Installed" (missing locally); the system initiated multi-source matching: the local cached source returned "No such resource"; the enterprise private source detected that the server's current load rate is 15% (idle) and version 1.0.0 exists; the official public source has a high network latency (200ms), but the corresponding version also exists; the matrix generated by the matching results shows that the enterprise private source is the best available source.

[0068] First iteration: The system marks the local cache source as "unavailable," while the enterprise private source and the official public source are marked as "available." Second iteration: The system compares version information and confirms that both are version 1.0.0, marking them as "version matched." Third iteration: The system compares network load; the enterprise private source has a latency of 5ms (marked as "extremely fast"), while the official public source has a latency of 200ms (marked as "relatively slow"). After three iterations, the enterprise private source wins in the comprehensive comparison.

[0069] Based on the iterative results, the system extracts download elements from the enterprise's private repository: source address, internal network authentication token Token-A, and file SHA256 hash value; the system then integrates these elements to construct a complete download event object.

[0070] The DownloadEvent(HighPrecisionVision,Source=Enterprise,Priority=Medium) event is pushed to the download queue, triggering the actual file transfer process and ensuring that the method component can be loaded into the platform in an efficient and secure manner.

[0071] refer to Figure 4 In step S13, the specific steps are as follows:

[0072] S131: Monitor download events in real time, identify multiple nodes during the monitoring process, determine the corresponding dependency tree based on the location of each node, the corresponding node content and the download process of the download event, and trigger the detection of the dependency tree. During the detection of the dependency tree, mark the corresponding conflict nodes and determine the corresponding conflict content by tracing the conflict nodes.

[0073] S132: Mark the constraint relationship corresponding to the conflict content, determine multiple constraint elements by traversing the constraint relationship, determine the corresponding conflict resolution method according to the mapping relationship between multiple constraint elements, conflict content and conflict resolution method, collect the framework compatibility corresponding to the dependency tree, and iterate on the conflict resolution method and framework compatibility to output the corresponding target framework, and mark the framework content of the target framework. The framework content presents the loading process of each function package and the corresponding version conflict control content.

[0074] In the embodiments of this application, download events are monitored in real time, and multiple nodes are identified during the monitoring process. Based on the location of each node, the corresponding node content, and the download process of the download event, the corresponding dependency tree is determined, and the detection of the dependency tree is triggered. During the detection process of the dependency tree, the corresponding conflict nodes are marked, and the corresponding conflict content is determined by tracing the conflict nodes. This approach takes into account the overall consideration of the location of each node, the corresponding node content, and the download process of the download event, ensuring the accuracy of the corresponding dependency tree.

[0075] At this point, the download scheduler starts an event listening thread to track the execution status of the download events constructed in step S122 in real time. During the monitoring process, the system parses the metadata header information in the download stream to identify "nodes". These nodes are not network nodes, but rather logical units in the dependency topology graph, including the root node (target function package) and its directly referenced child nodes (dependency libraries). The system extracts the unique identifiers and version declarations of these nodes in real time and maps them to topology objects in memory.

[0076] The system performs a recursive construction method based on the reference relationships (locations) between nodes and the metadata content; the root node is located at the top of the topology hierarchy, and the dependencies declared in its nuspec file are the first-level child nodes; as the download process progresses, each newly downloaded dependency package is parsed in real time, and its internal dependency declarations are further expanded to form second-level and third-level child nodes; the system aggregates these scattered node data streams to build a complete dependency tree structure with directed edge dependencies.

[0077] Once the dependency tree is constructed, the parsing layer immediately triggers a conflict detection routine. The system traverses all edges in the dependency tree to check for "diamond dependencies" or "version conflicts." That is, it checks whether multiple parent nodes reference the same child node package, but the required version ranges are mutually exclusive (no intersection). If such an anomaly is detected, the system marks the child node as a "conflicting node" and highlights its conflict path in the topology graph.

[0078] The system initiates a reverse tracing mechanism, starting from the conflict node and traversing upwards along the edges of the dependency tree until all root paths causing the conflict are located. The system extracts the specific conflict content and generates a detailed conflict report, which includes: the conflict node ID, a list of conflicting version numbers (such as version A and version B), and a list of parent nodes that caused the conflict. This information provides accurate data support for the subsequent arbitration process.

[0079] Specifically, the system monitors the download event of "high-precision visual positioning method" and parses out the root node as HighPrecisionVision (version 1.0.0). When downloading its metadata, the system identifies two key child nodes that it depends on: ImageProcessingCore (image processing core library) and MotionControlInterface (motion control interface library).

[0080] As the download progressed, the system analysis revealed that: HighPrecisionVision (root node) depends on ImageProcessingCore version ≥ 4.0.0; HighPrecisionVision (root node) also depends on MotionControlInterface version ≥ 2.0.0; further downloading revealed that MotionControlInterface (first-level child node) internally depends on ImageProcessingCore version ≥ 3.0.0 < 3.5.0; based on this, the system constructed a dependency tree, with ImageProcessingCore becoming a key referenced node in this tree.

[0081] The system checks the dependency tree and finds that the node ImageProcessingCore has a version constraint conflict: Path 1 (from the root node): requires version ≥ 4.0.0; Path 2 (from the first-level child node): requires version ≥ 3.0.0 < 3.5.0. These two version ranges have no overlap, so the system marks ImageProcessingCore as a red "conflicting node".

[0082] The system traces upwards along the conflict node to determine the details of the conflict: Conflict Node ID: ImageProcessingCore; Conflict Description: The target component requires the use of OpenCV 4.0 or higher interfaces (corresponding to ImageProcessingCore 4.0+), while its dependent motion control interface is only compatible with the OpenCV 3.x environment (corresponding to ImageProcessingCore 3.x); Conflict Source: The parent nodes are HighPrecisionVision and MotionControlInterface, respectively; The system encapsulates the conflict content and the complete tracing path into an exception object, awaiting arbitration processing in step S132.

[0083] Furthermore, the constraints corresponding to the conflicting content are marked, and multiple constraint elements are determined by traversing these constraints. Based on the mapping relationship between multiple constraint elements, conflicting content, and conflict resolution methods, the corresponding conflict resolution methods are determined. At the same time, the framework compatibility corresponding to this dependency tree is collected, and the conflict resolution methods and framework compatibility are iterated to output the corresponding target framework. The framework content of the target framework is marked. This framework content presents the loading process of each functional package and the corresponding version conflict control content, taking into account the overall consideration of the mapping relationship between multiple constraint elements, conflicting content, and conflict resolution methods, and ensuring the accuracy of the corresponding conflict resolution methods.

[0084] At this point, after identifying a conflict node, the system extracts the version constraints (i.e., constraint relationships) declared for that node in different paths of the dependency tree; the parser traverses along the edges of the dependency tree, collecting all constraint declarations pointing to the conflict node; each constraint declaration is parsed into specific "constraint elements", including: minimum version number, maximum version number, whether it contains a pre-release version, and a specific version range expression; the system aggregates these scattered constraint elements into a set of constraints to be processed.

[0085] The system calls the conflict arbitration engine to perform logical operations on the constraint set; it mainly checks whether there is an intersection between the constraint elements; if there is an intersection, the system determines the solution according to the preset "most recent winner" or "highest version" strategy, usually selecting the version number that satisfies all constraints; if there is no intersection (i.e. deadlock conflict), the system maps the "rollback compatibility" method or the "user intervention" method, tries to find a compatible old version or throws an exception. This process transforms the abstract constraint conditions into specific version selection instructions.

[0086] While resolving version conflicts, the system scans the TargetFramework identifier of each node in the dependency tree. The system executes a framework compatibility iteration method: initial iteration value: based on the runtime framework of the host program (such as .NET 6.0); iteration process: check whether the component versions selected by conflict resolution methods contain assemblies that are compatible with the current framework; if incompatible, trigger fallback logic to find a suboptimal solution within the range of compatible versions. This is a double loop iteration process, with the outer loop handling version conflicts and the inner loop verifying framework compatibility, until a set of components that has no version conflicts and meets the framework requirements is found.

[0087] After iterative convergence, the system locks the final target runtime framework (such as .net6.0) and outputs "framework content". This framework content is not just a framework identifier, but a data structure that contains the paths of all assemblies to be loaded, a list of dependency version locks, and conflict resolution logs. It fully records the status of each package in the current loading process, as well as the specific control measures taken for potential conflicts (such as version downgrading or patch loading), forming the final execution blueprint.

[0088] Specifically, for the ImageProcessingCore conflict node found in S131, the system marks its constraint relationship and traverses the dependency tree: Path 1 (from the root node): constraint relationship is ≥4.0.0; the system extracts the constraint element as: MinVersion=4.0.0, no upper limit; Path 2 (from the motion control interface): constraint relationship is ≥3.0.0<3.5.0; the system extracts the constraint element as: MinVersion=3.0.0, MaxVersion=3.5.0 (not included).

[0089] The system queried the mapping table and found that the conflict could not be resolved by simply "taking the highest version of the intersection". The system then activated the alternative solution: "dependency isolation and rollback". The system searched the historical version repository of ImageProcessingCore and found that version 3.5.0-beta had fixed the compatibility interface. Although the root node requires version 4.0, the system detected that the HighPrecisionVision package has a "downgrade compatibility mode". Therefore, the system determined the solution to be: enforce the version arbitration strategy, recommend the use of version 3.5.0, and prompt the root node component to enable compatibility mode.

[0090] The system identifies the current platform runtime environment as .NET 6.0 (.net6.0). The system then begins iterative verification: confirming whether the selected ImageProcessingCore 3.5.0 contains the lib / net6.0 directory; the verification result is "yes"; next, it checks whether other dependencies, such as MotionControlInterface, support .net6.0; the verification result is "yes"; during this process, the system discovers an indirect dependency, System.Drawing.Common, which has a platform compatibility warning under .net6.0. The system iteratively adjusts its strategy, replacing it with a platform-specific compatibility package.

[0091] The system outputs a target framework of .NET 6.0. The generated framework's content data structure is recorded as follows: Load Manifest: HighPrecisionVision (1.0.0), ImageProcessingCore (3.5.0) (marked as "Conflict Downgrade"), MotionControlInterface (2.0.0). Version Conflict Management Log: Records the decision process for downgrading ImageProcessingCore from the root node's expected 4.0.0 to 3.5.0 to resolve deadlock conflicts. Assembly Path Mapping: All components point to DLL files in the lib / net6.0 directory.

[0092] refer to Figure 5 In step S14, the specific steps are as follows:

[0093] S141: Monitor the loading process of each function package in real time, mark the corresponding heterogeneous functional components during the monitoring process, perform load detection on the heterogeneous functional components, and present the corresponding load content during the detection process. Determine multiple sub-load items based on the identification of the load content, determine the corresponding optimization content based on the multiple sub-load items and the current working state of memory, and optimize the corresponding memory usage along the optimization content.

[0094] S142: Collect the state tracking mechanism of each function package, detect the state tracking mechanism, identify multiple state tracking items during the detection process, detect the memory usage along the multiple state tracking items, identify multiple lifecycle nodes of heterogeneous functional components, and mark the corresponding component management content in each lifecycle node.

[0095] S143: Construct corresponding lifecycle management based on multiple lifecycle nodes. In this lifecycle management, mark heterogeneous functional components that are in use, introduce an online protection mechanism for heterogeneous functional components that are in use, and dynamically perform multi-stage protection for heterogeneous functional components that are in use.

[0096] In the embodiments of this application, the loading process of each functional package is monitored in real time. During the monitoring process, the corresponding heterogeneous functional components are marked. At this time, the load of the heterogeneous functional components is detected, and the corresponding load content is presented during the detection process. Multiple sub-load items are determined by identifying the load content. The corresponding optimization content is determined based on the current working state of the multiple sub-load items and memory. The memory usage is optimized along the optimization content. This approach takes into account the overall consideration of the current working state of multiple sub-load items and memory, ensuring the accuracy of the corresponding optimization content.

[0097] At this point, the system deploys probes in the "loading layer" to track the entire process of the function package from decompression to type registration in real time; the monitor captures the state changes of the components, such as "metadata loaded", "assembly parsed", "type registered", etc.; during this process, the system marks the instantiated objects and binds the managed objects to the function package identifiers to which they belong. This marking mechanism establishes a mapping relationship between objects and packages, enabling subsequent resource statistics to accurately trace back to the specific heterogeneous function components.

[0098] The system calls the application domain monitoring interface of the runtime environment to perform load detection on the marked heterogeneous functional components; the detector periodically samples to obtain the real-time load data of the component in memory; the load content includes, but is not limited to: the physical memory size occupied by the component assembly, the number of currently alive instance objects, and the activity of the component's internal thread pool. This data is aggregated into a visual load report to intuitively present the component's resource consumption.

[0099] The system performs in-depth analysis of the aggregated workload content, breaking it down into specific "sub-workload items," which include: metadata sub-workload: space occupied by type definitions, method tables, and reflection metadata; static resource sub-workload: unmanaged resources such as images, configuration files, and model files loaded by the component; instance object sub-workload: the size of specific business objects allocated in heap memory; and handle sub-workload: the number of file handles and network connection handles held by the component. By identifying sub-workload items, the system can accurately locate the resource consumption hotspots of the component.

[0100] The system will perform correlation analysis between the identified sub-load items and the current memory operating status of the system (such as available memory threshold, memory fragmentation rate, GC pressure). If the static resource sub-load is too large and the component is in an inactive state, the system will generate "resource release" optimization content to force the Unload operation or resource reclamation. If the metadata sub-load is redundant, the system will generate "lazy loading" optimization content to adjust the loading strategy of subsequent similar components. The system will execute instructions based on the generated optimization content, such as triggering garbage collection (GC), compressing memory pages, or unloading unnecessary dependencies, thereby minimizing memory usage while ensuring normal functionality.

[0101] Specifically, the "High Precision Vision Positioning Method" component begins loading; the system monitors that its main assembly HighPrecisionVision.dll has been injected into memory, and then creates a ComponentMonitor object, marking all types in the assembly (such as VisionProcessor, CoordinateTransformer) as belonging to PackageId:HighPrecisionVision.

[0102] The system performed a load test on the vision component and found that it was currently using 150MB of dedicated memory. The load report showed that this value was far higher than the average level of components in normal mode (usually 50MB). The system further presented detailed indicators: the number of handles was normal, but the heap memory allocation continued to increase, indicating that there were resource-intensive operations.

[0103] The system conducted an in-depth analysis of the load content and broke it down into the following sub-load items: Method Model Sub-load: It was identified that a large deep learning model file (Model.dat) was loaded inside the component, occupying 100MB of memory; Image Cache Sub-load: It was identified that the image preprocessing module cached 10 frames of high-resolution images, occupying 40MB; Metadata Sub-load: Reflection data and type definitions occupied 10MB.

[0104] The system detected that the current industrial control computer's remaining memory space is less than 20% (current working status is under pressure); for the "image cache sub-load", the system generated "dynamic release strategy" optimization content: the instruction component releases image cache that has been idle for more than 1 minute; for the "mode model sub-load", the system generated "paging loading strategy" optimization content: split the model file and load only the layers required for the current calculation into memory; after the system executes the optimization instructions, the memory usage of the "high-precision visual positioning mode" component is reduced from 150MB to 60MB, effectively alleviating the system's memory pressure and ensuring the smooth operation of the industrial automation platform.

[0105] Furthermore, the state tracking mechanism of each functional package is collected, the state tracking mechanism is tested, and multiple state tracking items are identified during the testing process. The memory usage is detected along multiple state tracking items, and multiple lifecycle nodes of heterogeneous functional components are identified. The corresponding component management content is marked in each lifecycle node. This approach takes into account the overall consideration of detecting memory usage by multiple state tracking items, ensuring the accuracy of multiple lifecycle nodes of heterogeneous functional components.

[0106] At this point, the system extracts the pre-set state tracking configuration of each functional package from the package management context. This mechanism is usually embedded in the metadata or main program assembly of the functional package in the form of event hooks, heartbeat detection proxies or lifecycle interfaces. The system activates these mechanisms through reflection or dependency injection to obtain the collection channel of component running status and establish a data link for subsequent real-time monitoring.

[0107] The system analyzes and verifies the collected tracking mechanisms to identify specific "state tracking items." These items constitute the component monitoring indicator system, which mainly includes: reference count: the number of times the component is called by other modules or workflows; handle holdings: the number of resources such as currently open file handles and network connections of the component; instance liveness status: the number of component instance objects currently alive in memory; and locked status: whether the component is in a critical section of atomic operation or thread locking.

[0108] The system uses state tracking items as indexes to delve into the runtime memory stack for detection; for each tracking item, the system maps its corresponding memory usage data; for example, it locates the frequently called object pool through reference counting items and detects its memory growth rate, and detects unmanaged memory leaks through handle holding items; the system establishes a "state-memory" relationship graph to clarify the specific impact weight of the component's current running state on memory resources.

[0109] Based on the detected state data and component runtime sequence, the system defines and divides the lifecycle nodes of the components. Typical nodes include: instantiation node: object creation and resource allocation phase; running node: business logic execution and data interaction phase; idle node: task completed but resources not released phase; pre-destruction node: resource reclamation and garbage collection (GC) phase. The system marks each node with control content, such as marking "running node" as "allow dynamic expansion", "idle node" as "trigger resource reclamation detection", and "pre-destruction node" as "forced unloading protection". These markings constitute the basis for the execution of automated lifecycle management.

[0110] Specifically, the system identified that the "high-precision visual positioning method" component implements the ITrackableComponent interface, and thus activated its internal state tracking agent. This agent is designed to report the execution status of the method threads and the allocation status of the image cache to the monitoring system. The system parses the data structure reported by the agent and identifies four core state tracking items: Algorithm_Thread_Count (number of method threads); Image_Cache_Size (image cache size); Pending_Tasks (length of the pending task queue); and Active_Cameras (number of active camera connections).

[0111] The system uses the above items to perform targeted memory detection: along the Image_Cache_Size item, the system detected that the component occupied 200MB of unmanaged image data memory, and this value did not decrease after the task was completed, indicating that there was cache retention; along the Active_Cameras item, the system detected that the component held 2 camera driver instances, occupying 15MB of driver buffer.

[0112] Based on the detection data, the system constructed a lifecycle management chain for this component: Node 1: Initialization phase; the management content is marked as "dependency injection check" to ensure that all visual library dependencies have been loaded; Node 2: High-frequency operation phase; the management content is marked as "memory circuit breaker protection" to set a memory threshold and prevent image processing overflow; Node 3: Task suspension phase; due to the detection of cache retention, the system marks the management content as "active resource release instruction" at this node, instructing the component to execute the ClearCache operation to reclaim the 200MB of idle memory; Node 4: Unload request phase; the system detects that Pending_Tasks=0 and marks the management content as "safe uninstallation permission", allowing subsequent execution of the uninstallation process.

[0113] Therefore, a corresponding lifecycle management system is constructed based on multiple lifecycle nodes. In this lifecycle management system, heterogeneous functional components in use are marked, and an online protection mechanism is introduced for these components. Furthermore, multi-stage protection is dynamically applied to these components, taking into account the overall consideration of multiple lifecycle nodes and ensuring the accuracy of the corresponding lifecycle management. Simultaneously, it considers conflict resolution methods and framework compatibility, improving the accuracy of the target framework. Memory usage is also optimized synchronously, enhancing the lifecycle management effect of heterogeneous functional components and providing online protection for these components in use.

[0114] At this point, the system constructs a finite state machine model based on the lifecycle nodes identified in step S142 (such as instantiation, running state, idle state, and before destruction). This finite state machine model defines the legal transition paths and triggering conditions of the component between each node. The lifecycle manager acts as the central controller, listening to the state transition events of the component and controlling the transition behavior of the component according to the preset rule engine to ensure that the component runs strictly according to the defined lifecycle trajectory.

[0115] Within the context of the lifecycle manager, the system determines the current state of components in real time. When a component is in the "running state" or is held by a business process (such as a workflow editor or an executing task queue), the system marks its state as "in use". This mark is not just a boolean value, but a composite state object that includes reference context, lock timestamp, and call chain information. The system synchronizes this state to the global component registry, making it logically invisible to destructive operations such as uninstallation and overwriting.

[0116] The system activates an "online protection mechanism," which is a set of interception and fault tolerance strategies. It is implemented by embedding protective proxies at the component's operation interface layer. When a potentially risky operation targeting the component (such as an uninstallation request, a version replacement request, or a file deletion request) is detected, the protection mechanism triggers an interceptor. The interceptor automatically blocks the operation based on the component's "in use" flag and returns a protective exception to the caller or redirects to a safe operation (such as redirecting "uninstall" to "marked for uninstallation"). At the same time, the mechanism also locks the component's physical file attributes to prevent external processes from writing to it.

[0117] The system implements a multi-dimensional "multi-section protection" strategy, covering all aspects of component operation: Memory protection section: In the runtime memory pool, the GC (garbage collection) priority of the component object is increased to avoid it being incorrectly collected, and external interference is isolated through memory barrier technology; Logic protection section: At the workflow engine level, the node instance corresponding to the component is locked, and editing or deletion operations are prohibited to ensure the integrity of the business logic chain; Dependency protection section: The versions of the underlying libraries that the component depends on are frozen, and hot updates of dependent libraries are prohibited during component operation to prevent runtime crashes caused by changes in dependent libraries.

[0118] Specifically, based on the nodes determined in S142, the system constructs a lifecycle state machine for the "high-precision visual positioning method". This state machine clearly stipulates that the component must go through the complete link of initialization > camera connection > method loading > operation detection > result output > resource release. The state machine locks the flow logic to ensure that the component will not directly enter the "operation detection" state before the "method loading" is completed.

[0119] At this moment, a vision inspection task in the industrial field is calling the "high-precision vision positioning method"; the system detects that the VisionProcessor object inside the component is processing image data, and the workflow instance Workflow_001 holds a reference to the component; the system then updates the status flag of the component in the lifecycle manager to IN_USE (in use) and binds the associated task ID.

[0120] While the component was running, the operations and maintenance personnel attempted to uninstall the old version of the "High Precision Vision Positioning Method" component package through the management interface. The system's online protection mechanism was triggered: the interceptor captured the Uninstall command, detected that the current component status was IN_USE, immediately blocked the uninstallation operation, and returned an error message to the interface: "The component is in the detection task, uninstallation is prohibited"; at the same time, the file system monitor locked the HighPrecisionVision.dll file, making it read-only.

[0121] The system implements comprehensive multi-section protection: Logic protection section: In the process flow editor, nodes using this method become locked (red border), and operators cannot modify their parameter configurations or delete the node, preventing the running logic from being tampered with; Dependency protection section: When the system detects a new version update request for the OpenCV library that the component depends on, the protection mechanism automatically suspends the update and puts the new version into a waiting queue. The update of the dependency library is only allowed after the component completes the current detection task and switches to the "idle state", thus ensuring the absolute stability of the detection process.

[0122] Please see Figure 6 , Figure 6 This is a schematic diagram of the structural composition of the lifecycle management system for heterogeneous functional components in an embodiment of the present invention; the lifecycle management system for heterogeneous functional components is applied to the above-described lifecycle management method for heterogeneous functional components; the lifecycle management system for heterogeneous functional components includes:

[0123] Function package module 21 is used to determine the corresponding component protocol based on the detection of the component database, trigger the encapsulation of multiple heterogeneous functional components along the component protocol, and output the corresponding function package. Each function package contains a nuspec metadata description file.

[0124] The download event module 22 is used to load multiple function packages into the corresponding multi-source management space, mark multiple sub-space sources in the multi-source management space, sort the priority of each sub-space source, and determine the corresponding download event by combining the cross-matching of each function package; the multiple sub-space sources include local cache sources, enterprise private sources and official public sources;

[0125] The conflict management module 23 is used to mark the corresponding dependency tree in the download event, determine the conflict content in the dependency tree detection, determine the corresponding conflict resolution method according to the conflict content and the corresponding constraint relationship, and determine the target framework in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts.

[0126] The lifecycle management module 24 is used to monitor the loading process of each function package in real time and mark the load of the corresponding heterogeneous function components in order to optimize the corresponding memory usage. Combined with the state tracking mechanism of each function package, it triggers the lifecycle management of heterogeneous function components and provides online protection for heterogeneous function components in use.

[0127] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.< / dependencies> < / metadata> < / dependencies> < / description> < / authors> < / version> < / id>

Claims

1. A method for lifecycle management of a heterogeneous functional component, characterized in that, include: Based on the detection of the component database, the corresponding component protocol is determined, and multiple heterogeneous functional components are encapsulated along the component protocol to output the corresponding function package. Each function package contains a nuspec metadata description file. Multiple function packages are loaded into the corresponding multi-source management space, and multiple sub-sources are marked in the multi-source management space. The priority of each sub-source is sorted, and the corresponding download event is determined by combining the cross-matching of each function package. Multiple subspace sources include local cache sources, enterprise private sources, and official public sources; In this download event, the corresponding dependency tree is marked, and the conflict content is determined in the dependency tree detection. Based on the conflict content and the corresponding constraint relationship, the corresponding conflict resolution method is determined. The target framework is determined in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts. The loading process of each function package is monitored in real time, and the load of the corresponding heterogeneous function components is marked to optimize the memory usage. Combined with the state tracking mechanism of each function package, the lifecycle management of heterogeneous function components is triggered, and online protection is provided for heterogeneous function components that are in use.

2. The method of claim 1, wherein, The component protocol is determined based on the detection of the component database. Following this protocol, the encapsulation of multiple heterogeneous functional components is triggered, outputting corresponding function packages. Each function package contains a Nuspec metadata description file, including: The component database is collected, the component database is tested, and the corresponding protocol information is determined during the testing process. The corresponding component protocol is determined by tracing the protocol information. In the component protocol, the multi-dimensional protocol structure is determined based on the parsing of the component protocol.

3. The method of claim 2, wherein, The component protocol is determined based on the detection of the component database. Following this protocol, the encapsulation of multiple heterogeneous functional components is triggered, outputting corresponding function packages. Each function package contains a Nuspec metadata description file and also includes: Based on the detection of the multidimensional protocol structure, the corresponding encapsulation route is determined. Based on the encapsulation route, the encapsulation of multiple heterogeneous functional components is triggered, and the corresponding functional package is determined. In each functional package, each functional package contains a nuspec metadata description file. Based on the parsing of the nuspec metadata description file, the identification information, dependency tree, and component type identifier of the functional package are determined.

4. The lifecycle management method for heterogeneous functional components according to claim 1, characterized in that, The process involves loading multiple function packages into the corresponding multi-source management space, marking multiple sub-sources in the multi-source management space, sorting the priorities of each sub-source, and determining the corresponding download event by combining the cross-matching of each function package. Multiple sub-space sources include local cache sources, enterprise private sources, and official public sources, including: The system collects a preset multi-source management space, loads multiple function packages into the same multi-source management space along different channels, performs different dimensions of control in the multi-source management space, and outputs the corresponding subspace source along the corresponding dimension of control path to mark multiple subspace sources.

5. The lifecycle management method for heterogeneous functional components according to claim 4, characterized in that, The process involves loading multiple function packages into the corresponding multi-source management space, marking multiple sub-sources in the multi-source management space, sorting the priorities of each sub-source, and determining the corresponding download event by combining the cross-matching of each function package. Multiple subspace sources include local cache sources, enterprise private sources, and official public sources, and also include: The priority of multiple subspace sources is marked, and cross-matching is performed based on the status of each function package and the load of the multi-source management space. During the cross-matching process, the corresponding comparison results are marked in sequence, and multiple comparison results are iterated at multiple levels. During the iteration process, multiple download elements are determined, and multiple factors are fused based on multiple download elements to construct the corresponding download event. Multiple subspace sources cover local cache sources, enterprise private sources, and official public sources. Each of these sources has corresponding control logic. During the cross-matching process, it checks whether a copy of the function package already exists locally, and simultaneously detects the network latency and concurrent connection count of each subspace source.

6. The lifecycle management method for heterogeneous functional components according to claim 1, characterized in that, In this download event, the corresponding dependency tree is marked, and conflict content is determined during dependency tree detection. Based on the conflict content and corresponding constraints, the corresponding conflict resolution method is determined. The target framework is determined in conjunction with the corresponding framework compatibility to ensure that all functional packages can be loaded normally and version conflicts are avoided, including: The system monitors download events in real time and identifies multiple nodes during the monitoring process. Based on the location of each node, its corresponding content, and the download progress of the download event, the system determines the corresponding dependency tree and triggers the detection of the dependency tree. During the detection process, the system marks the corresponding conflict nodes and traces the conflict nodes to determine the corresponding conflict content.

7. The lifecycle management method for heterogeneous functional components according to claim 6, characterized in that, In the download event, the corresponding dependency tree is marked, and conflict content is determined during dependency tree detection. Based on the conflict content and corresponding constraints, the corresponding conflict resolution method is determined. The target framework is determined in conjunction with the corresponding framework compatibility to ensure that each functional package can be loaded normally and version conflicts are avoided. This also includes: The system marks the constraint relationships corresponding to the conflicting content, determines multiple constraint elements by traversing these constraint relationships, and determines the corresponding conflict resolution methods based on the mapping relationship between multiple constraint elements, conflicting content, and conflict resolution methods. At the same time, it collects the framework compatibility corresponding to the dependency tree and iterates on the conflict resolution methods and framework compatibility to output the corresponding target framework. The system also marks the framework content of the target framework, which presents the loading process of each function package and the corresponding version conflict control content.

8. The lifecycle management method for heterogeneous functional components according to claim 1, characterized in that, The system monitors the loading process of each functional package in real time and marks the load of the corresponding heterogeneous functional components to optimize memory usage. Combined with the state tracking mechanism of each functional package, it triggers lifecycle management of heterogeneous functional components and provides online protection for heterogeneous functional components in use, including: The loading process of each function package is monitored in real time. During the monitoring process, the corresponding heterogeneous functional components are marked. At this time, the load of the heterogeneous functional components is detected, and the corresponding load content is presented during the detection process. Multiple sub-load items are determined along the identification of the load content. Based on the multiple sub-load items and the current working state of memory, the corresponding optimization content is determined, and the memory usage is optimized along the optimization content.

9. The lifecycle management method for heterogeneous functional components according to claim 8, characterized in that, The real-time monitoring of the loading process of each functional package and the marking of the load of the corresponding heterogeneous functional components to optimize the corresponding memory usage, combined with the state tracking mechanism of each functional package to trigger the lifecycle management of heterogeneous functional components, and the online protection of heterogeneous functional components in use, also includes: Collect the state tracking mechanism of each functional package, test the state tracking mechanism, identify multiple state tracking items during the test, test the memory usage along the multiple state tracking items, identify multiple lifecycle nodes of heterogeneous functional components, and mark the corresponding component management content in each lifecycle node. A corresponding lifecycle management system is built based on multiple lifecycle nodes. In this lifecycle management system, heterogeneous functional components that are in use are marked, an online protection mechanism is introduced for heterogeneous functional components that are in use, and multi-stage protection is dynamically applied to heterogeneous functional components that are in use.

10. A lifecycle management system for heterogeneous functional components, characterized in that, The lifecycle management system for heterogeneous functional components is applied to the lifecycle management method for heterogeneous functional components as described in any one of claims 1-9; the lifecycle management system for heterogeneous functional components includes: The function package module is used to determine the corresponding component protocol based on the detection of the component database, trigger the encapsulation of multiple heterogeneous functional components along the component protocol, and output the corresponding function package. Each function package contains a nuspec metadata description file. The download event module is used to load multiple function packages into the corresponding multi-source management space, mark multiple sub-space sources in the multi-source management space, sort the priority of each sub-space source, and determine the corresponding download event by combining the cross-matching of each function package; the multiple sub-space sources include local cache sources, enterprise private sources and official public sources; The conflict management module is used to mark the corresponding dependency tree in the download event, determine the conflict content in the dependency tree detection, determine the corresponding conflict resolution method based on the conflict content and the corresponding constraint relationship, and determine the target framework in combination with the corresponding framework compatibility to ensure that each function package can be loaded normally and avoid version conflicts. The lifecycle management module is used to monitor the loading process of each function package in real time and mark the load of the corresponding heterogeneous function components in order to optimize the memory usage. Combined with the state tracking mechanism of each function package, it triggers the lifecycle management of heterogeneous function components and provides online protection for heterogeneous function components that are in use.

Images