Algorithm supermarket system based on new energy scene

Abstract

An algorithm supermarket system based on a new energy scene mainly comprises a user layer used for providing algorithm demand submission, result reception and feedback interaction for various users of new energy; the interface layer is used for providing a standardized calling entry; the scheduling layer is used for scheduling and distributing computing power resources; the adaptation layer is used for dynamically matching user requirements and algorithms; the algorithm resource layer is used for algorithm storage and management; the supporting module is used for providing data support, safety guarantee and monitoring evaluation; wherein after the adaptation layer matches a corresponding algorithm according to user requirements, the scheduling layer calls computing power resources and executes the algorithm according to a scheduling strategy. According to the system, efficient matching and calling of multiple types of new energy scenes and algorithm resources can be effectively realized, and the convenience of obtaining adaptive algorithm resources by new energy users is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of algorithm sharing and on-demand access technology in new energy scenarios, and particularly to an algorithm supermarket system based on new energy scenarios. Background Technology

[0002] With the rapid development of the new energy industry, the demand for various data processing and analysis is increasing. In new energy scenarios, different applications often require specific algorithms to process and analyze data. However, at present, specialized algorithm management systems for new energy scenarios are still in their infancy. Existing algorithm resources are scattered and lack a unified management and sharing platform, resulting in low development efficiency and serious resource waste. At the same time, new energy companies also face difficulties in finding suitable algorithms that meet their own needs quickly.

[0003] This is mainly because existing algorithm service platforms focus on a single field (such as only photovoltaic forecasting) or the general computer field, without designing adaptation mechanisms for the special characteristics of new energy scenarios. They cannot meet the core requirements of "cross-scenario compatibility, dynamic adaptation, low-latency invocation, and security and controllability", which restricts the efficiency of intelligent upgrading of new energy systems. Summary of the Invention

[0004] This disclosure provides an algorithm supermarket system suitable for new energy scenarios, which is applicable to the algorithm service architecture of the entire life cycle of new energy projects (planning and design, operation monitoring, optimization scheduling, operation and maintenance management). It can realize efficient matching, dynamic adaptation and secure calling of algorithm resources for multiple types of new energy scenarios.

[0005] The system comprises, from top to bottom: user layer, interface layer, scheduling layer, adaptation layer, algorithm resource layer, and supporting modules, among which: The user layer is used to provide algorithm request submission, result reception, and feedback interaction for various new energy users. The interface layer provides a standardized call entry point and supports multi-protocol adaptation. The scheduling layer is used for scheduling and allocating computing resources, prioritizing, and load balancing. The adaptation layer is used for dynamic matching of user needs with algorithms; The algorithm resource layer is used for algorithm storage, registration, review, and version management. Supporting modules are used to provide data support, security assurance, and monitoring and evaluation. The adaptation layer matches the corresponding algorithm according to the user's needs, and the scheduling layer calls computing resources to execute the algorithm according to the scheduling strategy.

[0006] Furthermore, the system adopts a hybrid deployment architecture of "cloud + edge": Cloud nodes: Deploy algorithm resource layers, scheduling layers, and support modules, and are responsible for centralized algorithm management, large-scale computing, and data storage; Edge nodes: Deploy lightweight adaptation layers, interface layers, and high-frequency call algorithms locally on new energy projects to meet low-latency call requirements; Data synchronization between the cloud and the edge is achieved through a communication network, including: algorithm version updates, uploading of operation logs, and synchronization of scene data.

[0007] Furthermore, the system uses tag settings to match user-submitted new energy scenarios with algorithm resources, wherein the tags include: (1) Applicable scenario tags for algorithm resources; (2) New energy scenario tags, including: The basic attribute tags for a scenario include one or more of the following: project type, installed capacity, device model, and geographic coordinates. Data tags include one or more of the following: data type, data format, and data sampling frequency; Requirement tags include one or more of the following: functional requirements, performance requirements, and optimization goals.

[0008] Furthermore, the storage content of the algorithm resource layer includes: algorithm execution package, algorithm metadata, test dataset, and historical running records; The algorithm execution package supports containerized deployment. Algorithm metadata includes: input and output parameters, applicable scenario tags, performance metrics, and one or more dependencies in the environment.

[0009] Furthermore, the specific method for the adaptation layer to dynamically match user needs with algorithm resources includes the following steps: Tag matching: After receiving user requirement tags, perform similarity calculations with the applicable scenario tags of the algorithm metadata, and filter candidate algorithms with a fit greater than a set threshold. Data adaptation: Automatically converts user input data format to the format required by the algorithm and completes missing data; Parameter calibration: Based on the new energy scenario parameters requested by the user, automatically adjust the built-in parameters of the algorithm, including: the feature weights of the prediction model and / or the constraints of the optimization algorithm; Compatibility verification: The executability of the adapted algorithm is verified through lightweight test cases to avoid runtime errors; Output the adaptation results.

[0010] Furthermore, the scheduling allocation strategy of the scheduling layer includes: (1) Decompose user requirements into functional requirements, performance requirements, and resource requirements; (2) Prioritize users based on their type and the urgency of their needs; Priority is calculated using a weighted summation formula, as follows:

[0011] in: , , These are the weighting coefficients; P: Priority score, the higher the score, the higher the priority; U: User type weight, where power grid dispatch center > new energy operator > third-party developer; E: Weight of urgency of demand, where real-time scheduling > near-real-time analysis > non-real-time planning; S: Scenarios importance weight, where grid security related > power generation efficiency related > operation and maintenance management related; (3) Allocate computing resources in order of priority from high to low; among them, computing nodes deployed at the edge should respond to the call requests of local new energy projects first in order to reduce network latency; (4) Monitor the CPU and / or memory usage of computing nodes in real time and allocate new computing power request requests to nodes with load ≤ set load threshold; With the goal of minimizing the load differences among computing nodes, the following optimization model is established:

[0012] Where N is the number of available computing nodes; Let be the real-time load rate of the i-th node; Average load rate of all nodes ; Constraints: ≤ Set load threshold; (5) Preemptive scheduling trigger: When a high-priority request arrives, the preemption of a low-priority task is triggered if the following conditions are met:

[0013] New request priority score; : Priority score of the currently running task; Priority difference threshold; Percentage of idle computing resources; : Idle resource threshold.

[0014] Furthermore, the standardized call entry points provided by the interface layer include: RESTful APIs are used to respond to non-real-time requests. The WebSocket interface is used to respond to real-time requirements; The SDK toolkit is designed for local deployment and supports multiple languages ​​including Java, Python, and C++.

[0015] Furthermore, the interactive functions set in the user layer include one or more of the following: user-defined algorithm parameters, viewing algorithm running logs, feedback on algorithm effects, and requesting customized modifications to the algorithm.

[0016] Furthermore, the supporting module includes: Data support module: Integrates real-time monitoring data, historical data, meteorological data, and power grid data of new energy sources, and provides data cleaning, fusion, and query services; Security module: Used to implement encrypted data transmission, algorithm call access control, isolated storage of user data, and encrypted deployment of core algorithm code; The monitoring and evaluation module is used to monitor the algorithm's running status and evaluate its effectiveness in real time. When the algorithm runs abnormally, it automatically triggers an alarm and switches to a backup algorithm.

[0017] Compared with the prior art, the beneficial effects of this disclosure are: ① Efficient reuse of algorithm resources: Integrating algorithms for all new energy scenarios, the reuse rate is increased to over 85%, reducing redundant development costs and shortening the intelligent implementation cycle of new energy projects; ② Adaptation costs are significantly reduced: Through the dynamic adaptation mechanism, the adaptation time between the algorithm and new energy projects is shortened from several weeks to minutes, and the adaptation cost is reduced by more than 70%; ③ Improved response timeliness: Edge deployment + multi-priority scheduling, real-time algorithm response latency ≤500ms, meeting the dynamic adjustment needs of new energy scenarios; ④ Optimized operational efficiency: The accuracy of power generation prediction for new energy systems has been improved to over 92%, energy storage revenue has increased by 10%-20%, grid absorption capacity has increased by 15%, and operation and maintenance costs have been reduced by 25%; ⑤ Open and win-win ecosystem: Supports third-party algorithm access and commercial operation. Algorithm providers can obtain revenue, and algorithm users can call on demand for a fee, forming an open and shared new energy algorithm ecosystem. Attached Figure Description

[0018] The above and other objects, features and advantages of this disclosure will become more apparent from the more detailed description of exemplary embodiments of this disclosure taken in conjunction with the accompanying drawings, in which the same reference numerals generally represent the same components.

[0019] Figure 1 The above is a diagram of the overall architecture of the new energy scenario algorithm supermarket based on this disclosure; Figure 2 Flowchart for dynamic adaptation of the adaptation layer; Figure 3 This is a schematic diagram of the priority scheduling logic of the scheduling layer. Detailed Implementation

[0020] Preferred embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.

[0021] This disclosure provides an algorithm supermarket system suitable for new energy scenarios. In one exemplary implementation, the overall architecture is shown in the attached figure. Figure 1 As shown, its core is to build a new energy scenario algorithm supermarket with "layered architecture + core mechanism + supporting modules". The specific technical solution is as follows: (I) Overall Architecture The algorithm marketplace adopts a five-layer architecture, from top to bottom: user layer, interface layer, scheduling layer, adaptation layer, and algorithm resource layer. It also includes data support modules, security modules, and monitoring and evaluation modules, forming a complete algorithm service system.

[0022] (II) Detailed Description of Core Module Functions 1. Algorithm Resource Layer Algorithm classification system: It is classified into three levels according to the new energy scenario dimension (photovoltaic, wind power, energy storage, microgrid, grid dispatch, etc.), the functional dimension (prediction, optimization, control, diagnosis, planning), and the performance dimension (real-time performance, accuracy level, computational complexity). Algorithm management mechanism: Supports algorithm registration (third-party developers submit algorithm packages, instructions, and test reports), review (technical review + scenario adaptability review), version management (retaining historical versions and supporting rollback), and removal mechanism (algorithms that fail to meet performance standards or pose security risks). Algorithm storage structure: Distributed storage is adopted, and the stored content includes algorithm execution package (supporting containerized deployment), algorithm metadata (input and output parameters, applicable scenario tags, performance indicators, dependent environment), test dataset, and historical running records.

[0023] 2. Adapter layer Scene Tagging System: Construct a standardized tag library for new energy scenarios, including: Basic tags: Project type (photovoltaic / wind power / energy storage, etc.), installed capacity, equipment model, geographical coordinates; Data tags: data type (real-time / historical / weather / load), data format (JSON / CSV / Protobuf), data sampling frequency; Requirements tags: Functional requirements (prediction / optimization / control), performance requirements (response latency ≤500ms / prediction accuracy ≥90%), optimization objectives (maximum benefit / minimum energy consumption / optimal absorption). Dynamic adaptation process: Tag matching: After receiving user requirement tags, perform similarity calculations with algorithm metadata tags to filter candidate algorithms with a fit of ≥80%; Data adaptation: Automatically converts user input data format to the format required by the algorithm and completes missing data (based on the data interpolation algorithm for new energy scenarios). Parameter calibration: Based on user scenario parameters (such as the tilt angle of the photovoltaic power station and the SOC threshold of the energy storage), automatically adjust the built-in parameters of the algorithm (such as the feature weights of the prediction model and the constraints of the optimization algorithm). Compatibility verification: The executability of the adapted algorithm is verified through lightweight test cases to avoid runtime errors.

[0024] The dynamic adaptation process of the adaptation layer is as follows: Figure 2 As shown.

[0025] 3. Scheduling Layer Requirements analysis: Break down user requirements into functional requirements, performance requirements, and resource requirements (computing resources / storage resources); Scheduling strategy: 1) Priority scheduling: Priorities are set based on user type (power grid dispatch center > new energy operator > third-party developer) and urgency of demand (real-time dispatch > non-real-time analysis). 2) Load balancing scheduling: Real-time monitoring of the CPU / memory utilization of algorithm nodes, and allocation of new algorithm call requests to nodes with a load ≤70%; 3) Local scheduling: Algorithm nodes deployed at the edge prioritize responding to call requests from local renewable energy projects (such as microgrids) to reduce network latency; Queue management: Low-priority requests are cached in a queue. When a high-priority request arrives, computing resources can be temporarily preempted (the low-priority request can resume execution after interruption).

[0026] The priority scheduling logic of the scheduling layer is as follows: Figure 3 As shown.

[0027] In this embodiment, the specific mathematical model of the scheduling algorithm is as follows: (1) Priority weight calculation model The algorithm call priority is quantified using a weighted summation method, as shown in the following formula:

[0028] in: P: Priority score (range 0-10, the higher the score, the higher the priority). U: User type weight (Power grid dispatch center = 10, new energy operator = 7, third-party developer = 4); E: Demand urgency weight (real-time scheduling = 10, near-real-time analysis = 6, non-real-time planning = 3); S: Scenario importance weight (grid security related = 10, power generation efficiency related = 7, operation and maintenance management related = 4); , , Weighting coefficients (default values ​​are 0.4, 0.3, and 0.3, respectively; administrators can adjust them dynamically).

[0029] (2) Load balancing scheduling objective function: To minimize the load differences among computing nodes, the following optimization model is established: Where:

[0030] N: Number of available computing nodes; : Real-time load rate of the i-th node (combined CPU and memory utilization, ranging from 0 to 1); Average load rate of all nodes ( ) Constraints: ≤0.7 (The load rate of a single node should not exceed 70% to avoid overload) (3) Preemptive scheduling triggering conditions When a high-priority request arrives, the preemption of a low-priority task is triggered if the following conditions are met:

[0031] New request priority score; : Priority score of the currently running task; Priority difference threshold (default = 3, configurable); Percentage of idle computing resources; : Idle resource threshold (default = 0.2, meaning that preemption is triggered when idle resources are less than 20%).

[0032] 4. Interface Layer and User Layer Standardized interfaces: Provides RESTful API (for non-real-time requirements, response latency ≤3s), WebSocket interface (for real-time requirements, response latency ≤500ms), and SDK toolkit (for local deployment requirements), supporting Java / Python / C++ multi-language calls; User access control is divided into three roles: administrator (algorithm review, system configuration), algorithm provider (algorithm registration, revenue viewing), and algorithm user (requirement submission, algorithm invocation), with identity authentication based on OAuth 2.0. Interactive features: Supports users to customize algorithm parameters, view algorithm running logs, provide feedback on algorithm performance (such as prediction bias rate), and request customized modifications to the algorithm.

[0033] 5. Support Module Data support module: Integrates real-time monitoring data of new energy (equipment operating status, power output), historical data (power generation data of the past 3 years), meteorological data (wind speed, light intensity, probability of rainfall), and power grid data (electricity price, load, dispatch instructions), and provides data cleaning, fusion, and query services; Security module: Implements data transmission encryption (TLS 1.3), algorithm call access control, isolated storage of user data, and protection of algorithm intellectual property rights (encrypted deployment of core algorithm code, exposing only the call interface); Monitoring and evaluation module: Real-time monitoring of algorithm running status (CPU / memory usage, response time), evaluation of algorithm performance (prediction accuracy, optimization benefits), and automatic alarm triggering and switching to backup algorithm when the algorithm runs abnormally (such as response latency exceeding the threshold or accuracy not meeting the standard).

[0034] Application Examples (I) System Deployment Architecture This algorithm marketplace adopts a hybrid deployment architecture of "cloud + edge": Cloud node: Deploys the algorithm resource layer (distributed algorithm library), scheduling layer, data support module, security module, and monitoring and evaluation module, and is responsible for centralized algorithm management, large-scale computing, and data storage; Edge nodes: Deploy lightweight adaptation layers, interface layers, and high-frequency call algorithms (such as real-time photovoltaic power generation prediction and energy storage charging and discharging control algorithms) on the local premises of new energy projects (such as photovoltaic power station control rooms and microgrid operation and maintenance centers) to meet low-latency call requirements; Communication mechanism: Data synchronization between the cloud and the edge is achieved through 5G / fiber optic networks (algorithm version updates, operation log uploads, and scene data synchronization), and the MQTT protocol is used to ensure the reliability of data transmission.

[0035] (II) Typical Application Process (Taking the Optimization of Charging and Discharging of Energy Storage Power Stations as an Example) Requirement Submission: Energy storage operators (algorithm users) submit requirements through the SDK toolkit, carrying scenario tags: project type (energy storage power station), installed capacity (100MWh), current SOC (60%), grid electricity price (peak hour 1.2 yuan / kWh, off-peak hour 0.3 yuan / kWh), load forecast data (JSON format), optimization goal (maximizing revenue), and performance requirements (response latency ≤1s). Requirement parsing and tag matching: After the interface layer receives the requirement, the scheduling layer breaks down the requirement parameters, the adaptation layer extracts the scene tags, and matches them with the metadata tags of "energy storage charging and discharging optimization algorithm" in the algorithm resource layer (adaptation degree 92%), and selects them as candidate algorithms; Dynamic adaptation: The adaptation layer converts the JSON format load data submitted by the user into the CSV format required by the algorithm, and automatically adjusts the algorithm constraints based on the installed capacity of the energy storage power station (100MWh) (the upper limit of charging and discharging power is set to 20MW). The effectiveness of the adaptation is verified through lightweight test cases. Resource scheduling: The scheduling layer identifies the requirement as real-time (response latency ≤ 1s), sets the priority to level two, and allocates idle computing nodes at the edge (load 65%). Algorithm execution and result return: The algorithm calls the energy storage charging and discharging optimization algorithm deployed at the edge, inputs the adapted data and parameters, calculates the charging and discharging strategy for the next 24 hours (charging to 90% SOC during off-peak hours 00:00-08:00, discharging during peak hours 10:00-14:00 and 18:00-22:00), and returns the result to the energy storage operator terminal via the WebSocket interface with a response latency of 420ms; Operation monitoring and feedback: The monitoring and evaluation module records the algorithm's running status in real time (CPU usage 35%, memory usage 28%). After applying this strategy, energy storage operators can report the actual benefits through the platform (such as a 12% increase in daily revenue). The platform optimizes the algorithm parameters based on the feedback data.

[0036] (III) Algorithm Update and Iteration Process Algorithm providers (such as research institutions) should submit new versions of energy storage charging and discharging optimization algorithms (with the addition of "grid frequency regulation requirements" adaptation function), and upload the algorithm execution package, update instructions, and test reports; Administrators conduct technical reviews (code security, functional integrity) and scenario adaptability reviews (verifying adaptability to different energy storage capacities and frequency regulation parameters) through the algorithm review unit. Once approved, the algorithm resource layer automatically stores the new version of the algorithm, retains historical versions (supports rollback), and synchronizes it to edge nodes; The platform pushes update notifications to users who have already used the algorithm. Users can choose to "upgrade immediately" or "keep the old version". The upgrade process does not affect the current algorithm usage.

[0037] In this embodiment, based on multi-dimensional label matching and parameter self-calibration, the algorithm achieves "zero-code adaptation" to different new energy scenarios; By combining the different real-time requirements of new energy scenarios, dynamic allocation and preemptive scheduling of computing resources are achieved through multi-priority algorithm scheduling. It provides full lifecycle management for new energy algorithms, covering closed-loop management of algorithm registration, review, deployment, update, and delisting, and supports the access of third-party algorithms and version iteration; It breaks down the algorithm barriers in new energy sub-scenarios and enables cross-scenario reuse of algorithms through standardized interfaces and adaptation layers.

[0038] The above technical solutions are merely exemplary embodiments of the present invention. For those skilled in the art, based on the application methods and principles disclosed in the present invention, it is easy to make various types of improvements or modifications, and not limited to the methods described in the specific embodiments of the present invention. Therefore, the methods described above are merely preferred and not restrictive.

Claims

1. An algorithm supermarket system based on new energy scenarios, characterized in that, From top to bottom, it includes: user layer, interface layer, scheduling layer, adaptation layer, algorithm resource layer, and supporting modules, among which: The user layer is used to provide algorithm request submission, result reception, and feedback interaction for various new energy users. The interface layer provides a standardized call entry point and supports multi-protocol adaptation. The scheduling layer is used for scheduling and allocating computing resources, prioritizing, and load balancing. The adaptation layer is used for dynamic matching of user needs with algorithms; The algorithm resource layer is used for algorithm storage, registration, review, and version management. Supporting modules are used to provide data support, security assurance, and monitoring and evaluation. The adaptation layer matches the corresponding algorithm according to the user's needs, and the scheduling layer calls computing resources to execute the algorithm according to the scheduling strategy.

2. The system according to claim 1, characterized in that, The system adopts a hybrid deployment architecture of "cloud + edge": Cloud nodes: Deploy algorithm resource layers, scheduling layers, and support modules, and are responsible for centralized algorithm management, large-scale computing, and data storage; Edge nodes: Deploy lightweight adaptation layers, interface layers, and high-frequency call algorithms locally on new energy projects to meet low-latency call requirements; Data synchronization between the cloud and the edge is achieved through a communication network, including: algorithm version updates, uploading of operation logs, and synchronization of scene data.

3. The system according to claim 1, characterized in that, The system uses tag settings to match user-submitted new energy scenarios with algorithm resources, wherein the tags include: (1) Applicable scenario tags for algorithm resources; (2) New energy scenario tags, including: The basic attribute tags for a scenario include one or more of the following: project type, installed capacity, device model, and geographic coordinates. Data tags include one or more of the following: data type, data format, and data sampling frequency; Requirement tags include one or more of the following: functional requirements, performance requirements, and optimization goals.

4. The system according to claim 3, characterized in that, The storage content of the algorithm resource layer includes: algorithm execution package, algorithm metadata, test dataset, and historical execution records; The algorithm execution package supports containerized deployment. Algorithm metadata includes: input and output parameters, applicable scenario tags, performance metrics, and one or more dependencies in the environment.

5. The system according to claim 4, characterized in that, The specific method for the adaptation layer to dynamically match user needs with algorithm resources includes the following steps: Tag matching: After receiving user requirement tags, perform similarity calculations with the applicable scenario tags of the algorithm metadata, and filter candidate algorithms with a fit greater than a set threshold. Data adaptation: Automatically converts user input data format to the format required by the algorithm and completes missing data; Parameter calibration: Based on the new energy scenario parameters requested by the user, automatically adjust the built-in parameters of the algorithm, including: the feature weights of the prediction model and / or the constraints of the optimization algorithm; Compatibility verification: The executability of the adapted algorithm is verified through lightweight test cases to avoid runtime errors; Output the adaptation results.

6. The system according to claim 1, characterized in that, The scheduling allocation strategy of the scheduling layer includes: (1) Decompose user requirements into functional requirements, performance requirements, and resource requirements; (2) Prioritize users based on their type and the urgency of their needs; Priority is calculated using a weighted summation formula, as follows: in: , , These are the weighting coefficients; P: Priority score, the higher the score, the higher the priority; U: User type weight, where power grid dispatch center > new energy operator > third-party developer; E: Weight of urgency of demand, where real-time scheduling > near-real-time analysis > non-real-time planning; S: Scenarios importance weight, where grid security related > power generation efficiency related > operation and maintenance management related; (3) Allocate computing resources in order of priority from high to low; among them, computing nodes deployed at the edge should respond to the call requests of local new energy projects first in order to reduce network latency; (4) Monitor the CPU and / or memory usage of computing nodes in real time and allocate new computing power request requests to nodes with load ≤ set load threshold; With the goal of minimizing the load differences among computing nodes, the following optimization model is established: Where N is the number of available computing nodes; Let be the real-time load rate of the i-th node; Average load rate of all nodes ; Constraints: ≤ Set load threshold; (5) Preemptive scheduling trigger: When a high-priority request arrives, the preemption of a low-priority task is triggered if the following conditions are met: New request priority score; : Priority score of the currently running task; Priority difference threshold; Percentage of idle computing resources; : Idle resource threshold.

7. The system according to claim 1, characterized in that, The standardized call entry points provided by the interface layer include: RESTful APIs are used to respond to non-real-time requests. The WebSocket interface is used to respond to real-time requirements; The SDK toolkit is designed for local deployment and supports multiple languages ​​including Java, Python, and C++.

8. The system according to claim 1, characterized in that, The interactive functions set up in the user layer include one or more of the following: user-defined algorithm parameters, viewing algorithm running logs, feedback on algorithm effects, and requesting customized modifications to the algorithm.

9. The system according to any one of claims 1-8, characterized in that, The supporting module includes: Data support module: Integrates real-time monitoring data, historical data, meteorological data, and power grid data of new energy sources, and provides data cleaning, fusion, and query services; Security module: Used to implement encrypted data transmission, algorithm call access control, isolated storage of user data, and encrypted deployment of core algorithm code; The monitoring and evaluation module is used to monitor the algorithm's running status and evaluate its effectiveness in real time. When the algorithm runs abnormally, it automatically triggers an alarm and switches to a backup algorithm.

Images