A multi-scene adaptation method, system and device based on coupling of nodalization and traditional algorithm standard SDK

Abstract

This application discloses a multi-scenario adaptation method, system, and device based on node-based coupling with a traditional algorithm standard SDK, relating to the field of algorithm technology. The method includes: for multiple types of traditional algorithms, performing node-based mapping and encapsulation of algorithm operators, establishing a two-level hierarchy of core nodes and scene nodes, and building a node resource pool to store and manage all nodes; then, standardizing the full dimensions of input / output, parameter configuration, and interaction interfaces; based on this, configuring parameters through a visual drag-and-drop process orchestration and debugging mechanism to generate a JSON-formatted node configuration file; receiving call request data from the target scene to generate scheduling instructions, retrieving and running the corresponding JSON-formatted node configuration file, obtaining the algorithm processing results and visualized image data, and then feeding back the response after encapsulation through a pre-set unified SDK external call interface. This application enables flexible customization, efficient expansion, and convenient reuse of traditional algorithms.

Description

Technical Field

[0001] This application relates to the field of algorithm technology, and in particular to a multi-scenario adaptation method, system and device based on node-based coupling with traditional algorithm standard SDKs. Background Technology

[0002] The practicality and flexibility of traditional algorithm SDKs (Software Development Kits) have become key factors restricting the efficient implementation of technologies. Currently, the implementation schemes of traditional standard algorithm SDKs in the industry can be mainly divided into two categories: monolithic encapsulation and modular decomposition. Each has its own emphasis in terms of architectural design, implementation logic, and applicable scenarios. Although they can meet basic algorithm reuse requirements, due to limitations in architectural design, they have significant shortcomings in customization capabilities, scalability, ease of use, and maintenance efficiency, making it difficult to adapt to the diverse and highly dynamic application scenarios in various industries. Specific shortcomings are as follows: (1) The customization capability is weak and cannot be adapted to personalized scenarios.

[0003] Monolithic SDKs solidify algorithm functionality and parameter ranges within a single module, supporting only simple adjustments to preset parameters and failing to adapt algorithm logic or input / output data formats to meet individual user needs. For example, if a user requires adding custom noise filtering rules to a filtering algorithm, existing monolithic SDKs cannot support this requirement and can only achieve this by modifying the SDK source code and recompiling, significantly increasing development costs and time.

[0004] While modular, split SDKs support the combination of multiple modules, the rules governing module combination, data flow formats, and dependencies are all constrained by underlying preset logic, making it impossible to freely customize the algorithm flow. If users need to adjust the module call order or insert custom processing logic between existing modules, they are often limited by the SDK's preset orchestration rules, or even unable to do so, making it difficult to adapt to diverse and personalized scenario requirements.

[0005] (2) Insufficient scalability, and great difficulty in algorithm iteration and functional expansion.

[0006] The existing SDK architecture is rigid. Whether it's a monolithic or modular solution, adding new algorithm features or iterating on existing algorithms requires modifying, compiling, and redeploying the entire SDK. For monolithic SDKs, new algorithms need to be integrated into existing monolithic modules, which can easily lead to module bloat and increased code coupling, thus affecting the stability of the original algorithms. For modular SDKs, new modules must strictly adhere to existing interface specifications and management mechanisms, and the scheduling logic of the module management center needs to be modified. As the number of new modules increases, the complexity of the SDK architecture grows exponentially, and the scalability drops significantly.

[0007] (3) Poor usability and low development and debugging efficiency.

[0008] Existing SDKs primarily rely on code calls or configuration files to implement algorithm calls and combinations. This places high demands on the technical skills of developers, requiring them to be proficient in the SDK's interface specifications, module logic, and calling rules. Non-specialized algorithm developers often find it difficult to quickly get started and complete algorithm combinations and debugging. Furthermore, existing SDKs lack visual development and debugging tools. Algorithm flow combinations and parameter adjustments all require operation through code or configuration files. During development, it's impossible to intuitively view the algorithm execution flow, data transfer process, and intermediate results. When failures occur, it's difficult to quickly locate the root cause of the problem, resulting in low debugging efficiency and significantly increasing development time and costs.

[0009] (4) The modules are highly coupled and the maintenance costs are high.

[0010] Monolithic SDKs integrate multiple algorithms into a single module, resulting in extremely high coupling between algorithms. Modifying the logic of one algorithm can easily interfere with the normal operation of other algorithms, making maintenance difficult. While modular SDKs reduce direct coupling between algorithms, strong dependencies and data flow still exist between modules. When a module is iterated and updated, all other modules and scheduling logic that depend on it need to be adjusted simultaneously, and maintenance costs increase exponentially with the number of modules.

[0011] Meanwhile, the existing SDK lacks a unified module management and version control mechanism, and compatibility issues are prone to occur when multiple versions of algorithms coexist and modules are upgraded and iterated, which further increases the difficulty and cost of maintenance. Summary of the Invention

[0012] The purpose of this application is to provide a multi-scenario adaptation method, system, and device based on node-based coupling with traditional algorithm standard SDKs, which can realize flexible customization, efficient expansion, and convenient reuse of traditional algorithms.

[0013] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a multi-scenario adaptation method based on the coupling of node-based architecture with traditional algorithm standard SDKs, including: For various traditional algorithms, we perform node-based mapping and encapsulation of algorithm operators, two-level hierarchical structure of core nodes and scene nodes, and build a node resource pool to store and manage all nodes. The input / output, parameter configuration, and interaction interface of all nodes in the node resource pool are standardized in all dimensions; wherein, after the interaction interface is standardized in all dimensions, at least a preset unified SDK external call interface is obtained; Based on a node resource pool defined by full-dimensional standardization, parameters are configured and node-based configuration files in JSON format are generated through a visual drag-and-drop process orchestration and debugging mechanism. The system uses the pre-defined unified SDK to call external interfaces, receives call request data from the target scenario, parses and transforms it to generate corresponding scheduling instructions; According to the scheduling instructions, the corresponding JSON-formatted node configuration file is retrieved and run to obtain the algorithm processing results and visualization image data. Then, the response is encapsulated and fed back through the external call interface of the preset unified SDK.

[0014] Secondly, this application provides a multi-scenario adaptation system based on node-based architecture coupled with traditional algorithm standard SDKs, including: The node architecture design module is used to perform node-based mapping and encapsulation of algorithm operators for various traditional algorithms, two-level layering of core nodes and scene nodes, and to build a node resource pool to store and manage all nodes. The node standardization definition module is used to standardize the input and output, parameter configuration, and interaction interface of all nodes in the node resource pool. After standardizing the interaction interface in all dimensions, at least a preset unified SDK external call interface is obtained. The visual orchestration module is used to configure parameters and generate node-based configuration files in JSON format through a visual drag-and-drop process orchestration and debugging mechanism based on a node resource pool defined in full dimensions. The interface adaptation module is used to call the interface externally through the preset unified SDK, receive the call request data of the target scenario, parse and convert it to generate the corresponding scheduling instructions; The dynamic scheduling module is used to retrieve and run the corresponding JSON-formatted node configuration file according to the scheduling instructions, obtain the algorithm processing results and visualization image data, and then respond and feed back the results after encapsulating the response of the external call interface through the preset unified SDK.

[0015] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs.

[0016] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application achieves fine-grained decomposition of algorithms through algorithm operator node mapping and encapsulation, and a two-level layering of core nodes and scene nodes. The independent operation characteristics of core nodes and scene nodes support free combination. All nodes in the node resource pool are standardized in all dimensions for input / output, parameter configuration, and interaction interfaces, meeting personalized parameter configuration needs and ensuring unified node interfaces and data formats, reducing compatibility issues during version iterations. Based on the node resource pool with fully standardized definitions, parameter configuration is performed through a visual drag-and-drop process orchestration and debugging mechanism, allowing for flexible adjustment of node order. The above processing breaks through the limitations of existing SDK customization, supporting full-dimensional customization of algorithm flow, parameter configuration, and function combinations. It can accurately adapt to the personalized needs of different industries and scenarios, achieving flexible adjustments without modifying the SDK source code.

[0017] Furthermore, a node resource pool is built to store and manage all nodes, enabling centralized management of core and scenario nodes. This facilitates unified module maintenance and version control, avoids interference from new features on existing modules, eliminates the need for complete redeployment, and allows for rapid algorithm iteration and functional expansion, thus enhancing scalability. Additionally, the application of a visual drag-and-drop workflow orchestration and debugging mechanism replaces code writing and complex configurations, making it intuitive and easy to understand. It also supports debugging, enabling rapid fault location and significantly improving debugging efficiency. The above-mentioned treatments in this application lower the barrier to entry for the SDK, allowing non-professional algorithm developers to quickly get started, while simplifying the debugging process, shortening the development cycle, and reducing development costs. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a multi-scenario adaptation method based on the coupling of nodeization and traditional algorithm standard SDK in one embodiment of this application.

[0020] Figure 2 This is a schematic diagram of the visual interactive interface.

[0021] Figure 3 This is a schematic diagram of the input image.

[0022] Figure 4 Output a visual image for the template matching node.

[0023] Figure 5Output a visualization image (corrected ROI) for the trigger node.

[0024] Figure 6 Output a visualization image for the color matching node.

[0025] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] A monolithic SDK integrates one or more related traditional algorithms into a single module, providing services through a unified interface. In its implementation, developers encapsulate the core logic of the target algorithm, parameter configuration rules, and input / output data processing flow into a single package, providing a fixed-format function interface (such as a C / C++ dynamic link library interface, a Java class library interface, or a Python package interface). Upper-layer applications can only obtain the algorithm's processing results by calling the preset interface and passing in parameters of a specified format.

[0028] Taking a certain image preprocessing SDK as an example, it integrates three algorithms—Gaussian filtering, edge detection, and image scaling—into a single module, providing only a unified "image_process" interface. Users must strictly follow the interface documentation requirements, inputting the original image data and algorithm type identifier. The SDK internally matches the identifier to the corresponding algorithm, completes the processing, and returns the result. Some SDKs of this type support basic parameter adjustments, such as filter kernel size and edge detection threshold, but the adjustable range and adjustment logic of these parameters are fixed in the encapsulation stage, failing to support user-defined extension requirements.

[0029] The core advantage of a monolithic SDK lies in its short development cycle and simple deployment operation. It is suitable for the needs of fixed algorithm functions and single application scenarios, and has been widely used in early industrial control, simple data processing and other scenarios.

[0030] To address the lack of scalability in monolithic SDKs, modular, split SDKs have gradually emerged. Their core idea is to break down traditional algorithms with different functionalities into independent modules. Each module encapsulates only the core logic of a single algorithm, while defining standardized inter-module interaction interfaces to support multi-module combination calls within a limited scope.

[0031] In practice, each algorithm is developed as a separate module. Each module has its own input / output data specifications, parameter configuration interfaces, and independent execution logic. The SDK is equipped with a module management center, which is responsible for loading, initializing, scheduling, and transferring data between modules. Upper-layer applications can call a single module through the module management center or chain multiple modules together according to the SDK's preset combination rules to complete complex tasks, as needed. For example, a data processing SDK may separate data cleaning, sorting, and statistical algorithms into three independent modules. Users can sequentially call the data cleaning module to process the raw data, then transfer the cleaned data to the sorting module through the module management center, and finally call the statistical module to generate the results. Data flow between modules must follow a fixed format.

[0032] Some advanced modular SDKs support custom module combination processes, but this requires writing complex configuration files or calling dedicated process orchestration interfaces. Furthermore, the dependencies between modules and data flow rules are limited by the underlying architecture, making dynamic and flexible adjustments impossible. Such solutions are often used in relatively complex scenarios requiring multiple algorithms to work together, such as medical image analysis and big data statistical analysis.

[0033] Node-based technology, with its modular and visual core advantages, breaks down complex functions into independent, reusable node units. Through the flexible combination and flow of nodes, complex task orchestration can be achieved, and its feasibility has been verified in fields such as process automation and visual programming. Based on this, deeply integrating the node-based concept with traditional algorithm standard SDKs addresses the pain points of existing SDKs in terms of customization, scalability, and ease of use, becoming an important direction for adapting to diverse scenario needs and promoting the efficient deployment of traditional algorithms.

[0034] This application addresses the technical pain points of existing SDKs through node-based decomposition, standardized definition, visual orchestration, and dynamic scheduling mechanisms, enabling flexible customization, efficient expansion, and convenient reuse of traditional algorithms.

[0035] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0036] In one exemplary embodiment, such as Figure 1 As shown, a multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDK is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both the terminal and the server. In this embodiment, it includes the following steps 101 to 105.

[0037] Step 101: For various traditional algorithms, perform algorithm operator node mapping and encapsulation, establish a two-level hierarchy of core nodes and scene nodes, and build a node resource pool to store and manage all nodes.

[0038] In a specific application, through the technical means of algorithm operator node mapping, hierarchical construction of secondary nodes, and centralized management of node resource pools, various traditional algorithms are encapsulated one-to-one into independent and runnable operator nodes, building a two-level architecture system of "core node-scenario node". At the same time, a node resource pool supporting the full life cycle management of nodes is established, realizing the fine-grained decomposition, loosely coupled independent operation, and flexible combination of traditional algorithms in different scenarios, achieving standardized management and efficient reuse of algorithm resources. Based on this, step 101 includes the following steps (11)-(13).

[0039] (11) By mapping and encapsulating the algorithm operator node, a class of traditional algorithms is encapsulated as an operator node; various traditional algorithms are encapsulated as independent operators, each algorithm corresponds to a node, and operators and nodes are mapped one-to-one. This supports the collaborative operation of multiple algorithms through node combination. The design logic of its node configuration file is similar to that of the modular split SDK configuration file, but it focuses more on flexible combination and unified scheduling.

[0040] (12) Based on multiple operator nodes, construct a core node-scene node two-level architecture.

[0041] Specifically, any one of the operator nodes is taken as a core node. Each core node encapsulates the logic, parameter configuration, and input / output interface of the corresponding algorithm, specifically the core logic, basic parameter configuration, and standard input / output interface. It has an independent operating environment and is not coupled with each other. The algorithm operators corresponding to the core nodes include: machine vision operators, data processing operators, and detection operators.

[0042] The core nodes specifically include: camera calibration operator, image distortion correction operator, image homography transformation operator, image stitching operator, QR code recognition operator, DM code recognition operator, data compression operator, data decompression operator, template generation operator, template matching operator, color matching operator, dilation and erosion operator, diameter detection operator, grayscale detection operator, calibration plate generation operator, thresholding operator, etc.

[0043] Multiple core nodes are combined according to preset rules to obtain scene nodes adapted to corresponding business scenarios; such as a color recognition scenario of "template matching + ROI correction + color matching" and a light and dark code recognition scenario of "template matching + ROI slicing + OCR recognition + QR code recognition + edit distance". The scene nodes support secondary editing and modification, and their combination logic is defined through node-based configuration files. They can be directly implemented as complete business algorithm processes without additional layers, adapting to the flexible calling requirements of different scenarios.

[0044] (13) Build a node resource pool to store and manage all core nodes and scene nodes covered in the core node-scene node two-level architecture, support the addition, deletion, update and query of the core nodes and scene nodes, realize standardized management and efficient reuse of nodes, and facilitate batch management of machine vision and detection operators.

[0045] Step 102: Standardize the input / output, parameter configuration, and interaction interface of all nodes in the node resource pool. After standardizing the interaction interface, at least a preset unified SDK external call interface is obtained.

[0046] Through the technical means of formulating standardized specifications across all dimensions and developing standardized encapsulation tools for third-party algorithms, the unified definition of node input / output formats, parameter configuration rules, and internal / external interaction interfaces is completed. At the same time, lightweight encapsulation tools are provided to achieve seamless connection between different algorithm nodes, automatic data conversion and unified interface calls, as well as rapid encapsulation and non-intrusive access of third-party algorithms, solving the problems of poor compatibility and difficulty in expansion of traditional SDK nodes. Based on this, step 102 includes the following steps (21)-(23).

[0047] (21) In terms of input and output, define the data format and adaptation rules of any node, define the data conversion rules between different nodes, and determine the correspondence between the input and output data structure of the node and the parameters of the preset unified SDK external call interface.

[0048] Establish unified node standardization specifications to ensure that different algorithm operator nodes (including camera calibration, code recognition, detection, etc.) can be flexibly connected, combined, and interact with data, while adapting to unified interface call requirements.

[0049] Regarding the standardization of input and output, a common data format (such as JSON, binary stream, etc.) and adaptation rules are defined to support automatic data conversion between different nodes (such as seamless connection between camera calibration operator output and image distortion removal operator input), and the correspondence between input and output data structures and parameters of the preset unified SDK external call interface is clearly defined.

[0050] (22) In terms of parameter configuration, a unified parameter description format, adjustable range definition and default value are set for each core node, and user-defined parameter verification rules are defined.

[0051] For each core node (such as the kernel size of the dilation and erosion operator and the threshold range of the thresholding operator), a unified parameter description format, adjustable range definition and default value are set. User-defined parameter validation rules are supported. The combination logic and running parameters of all nodes are recorded through node-based configuration files in JSON format. The design concept of this configuration file is similar to that of the modular split SDK configuration file, but it is adapted to the flexible combination of core nodes and scene nodes.

[0052] (23) In terms of interaction interfaces, define the interaction interfaces between nodes and the preset unified SDK external call interface for external calls to ensure stable interaction between nodes and upper-layer applications and interfaces.

[0053] Furthermore, for third-party algorithms, a standardized encapsulation tool is invoked. Upon receiving a third-party algorithm, this tool is used to perform node-based adaptation and full-dimensional standardized definition, and then incorporate it into the node resource pool. This allows third-party algorithms to be quickly encapsulated into compliant core nodes, compatible with existing camera calibration, code recognition, and detection operator nodes, without requiring modification of the underlying SDK code, thus enabling flexible access and collaborative operation of third-party algorithms.

[0054] Step 103: Based on the node resource pool defined by full-dimensional standardization, the parameters are configured through a visual drag-and-drop process orchestration and debugging mechanism to generate a node-based configuration file in JSON format.

[0055] Through the development of a visual interactive interface, the division of functions into multiple regions, and the establishment of a process visualization debugging capability, a visual operation platform integrating node display, process editing, parameter configuration, and preview debugging is created. It supports drag-and-drop node combination, connected process arrangement, real-time parameter adjustment, and step-by-step breakpoint debugging, realizing code-free arrangement of algorithm processes and visual fault location, and significantly reducing the technical threshold for using the SDK. Based on this, step 103 includes the following steps (31)-(35).

[0056] (31) Construct a visual interactive interface; the visual interactive interface includes a visual node resource display area, a process editing area, a parameter configuration area, and a preview and debugging area, such as Figure 2 As shown. Specifically, it integrates a visual interactive interface, allowing users to combine nodes and arrange processes by dragging and dropping and connecting lines, without the need to write code or complex configuration files.

[0057] (32) Through the node resource display area, all nodes in the node resource pool defined in a full-dimensional standard are displayed, and the functions, parameters and applicable scenarios of each node are marked and displayed.

[0058] In one application, the node resource display area displays all nodes in the node resource pool according to their functions, including core nodes such as camera calibration, image processing, code recognition, and detection, and labels the function, parameters, and applicable scenarios of each node.

[0059] (33) Through the process editing area, users can combine nodes and arrange the sequential process by dragging and dropping nodes and connecting them. Users can also insert custom logic nodes.

[0060] In one application, the workflow editing area supports dragging and dropping nodes, connecting them with lines, and allows for intuitive adjustment of the node calling order (such as adjusting the execution order of "image distortion removal → thresholding → template matching"), and insertion of custom logic nodes (such as condition judgment nodes and loop nodes).

[0061] (34) Through the parameter configuration area, users can configure and adjust the parameters of each node and display the effect of parameter adjustment in real time.

[0062] In one application, the parameter configuration area allows for fine-tuning of parameters for each node (such as the detection range of the grayscale detection operator and the compression ratio of the data compression operator), and real-time preview of the effect of parameter modifications.

[0063] (35) Through the preview and debugging area, the sequential process of nodes after process editing and parameter configuration is supported to run step by step, breakpoint debugging, and intuitively display the running status, data flow process and intermediate results of each node (such as the image after the expansion and erosion operator is processed, and the recognition result of the QR code recognition operator). It also supports fault node location; after the user confirms the debugging is completed, a node configuration file in JSON format is generated.

[0064] Step 104: Through the external call interface of the preset unified SDK, receive the call request data of the target scenario, parse and convert it to generate the corresponding scheduling instruction.

[0065] By employing unified and standardized interface design, standardized definition of input and output parameters, and integrated request and response processing techniques, a unique SDK external call interface (i.e., a pre-defined unified SDK external call interface) is designed. Standardized input parameter structures and dual-key output parameter rules are established. An integrated processing logic for interface request parsing, data format conversion, and response result encapsulation is built to achieve unified calling of single / multi-node nodes and synchronous output of algorithm processing results and visual feedback. This replaces the traditional multi-interface distributed calling mode and reduces calling complexity.

[0066] The pre-defined unified SDK external call interface is as follows: `sbt::flow::process_SBT_FLOW_ALG(input,outputs)`; where `input` is the interface input and `outputs` is the interface output. `sbt::flow::` is the function namespace, `sbt / SBT` represents the naming tag, and `flow / FLOW` represents the scene flow, i.e., the concatenated flow after operator nodeization; `process_SBT_FLOW_ALG` is the function name, `ALG` stands for algorithm abbreviation, and `input` and `output` are variables representing the input and output of the traditional operator nodeization. All algorithm operators (single-node / multi-node combination) are called uniformly through this interface, completely replacing the existing multi-interface scattered call mode and reducing the calling complexity.

[0067] The interface input is speed::SVariantMap input, which is used to receive and store the data to be processed corresponding to the call request data and the corresponding JSON-formatted node configuration file; wherein, input["image"] stores the image data to be processed, and input["input"] stores the JSON-formatted node configuration file. The node configuration file contains core information such as node combination rules and the running parameters of each operator node, which forms a functional correspondence with the modular and split SDK configuration file but is adapted to the node architecture.

[0068] The interface output is std::map<int, speed::SVariantMap> The `outputs` property returns the result of a single node when a core node is invoked, and the results of all participating nodes when a scene node is invoked. Each node's output includes both the algorithm processing result and the visualized image data. Specifically, each node's output must contain two fixed keys: `output` (the algorithm processing result in JSON format) and `visual` (the visualized image data during the algorithm processing). This ensures synchronized output of data results and visual feedback, adapting to both debugging and business display needs. Additionally, the output of each sub-node is stored according to its node number.

[0069] This pre-defined unified SDK enables external API calls to parse API requests, convert data, and encapsulate responses.

[0070] Step 105: According to the scheduling instruction, retrieve and run the corresponding JSON-formatted node configuration file to obtain the algorithm processing results and visualization image data, and then encapsulate and feed back the response through the external call interface of the preset unified SDK.

[0071] By employing technical means such as building an intelligent scheduling engine, developing multi-dimensional scheduling capabilities, and designing an anomaly tolerance mechanism, an intelligent scheduling engine with node dependency resolution, dynamic load balancing, and dynamic process adjustment capabilities is constructed. Simultaneously, an anomaly retry mechanism, backup node switching, and fault alarm mechanism are designed to achieve optimized resource scheduling, highly dynamic real-time adjustment, and stable operation of the entire algorithm process, thereby improving algorithm execution efficiency and scenario adaptability. Based on this, step 105 includes steps (51) to (52).

[0072] (51) Build an intelligent dynamic scheduling engine to be responsible for the operation scheduling and resource optimization of the algorithm process; the intelligent dynamic scheduling engine is used to: automatically identify the dependency relationship between nodes (i.e., have the ability to resolve node dependencies) and optimize the calling order of nodes to avoid resource conflicts; support dynamic load balancing, and reasonably allocate computing resources according to the running time and resource occupation of each node to improve the overall running efficiency; have the ability to tolerate abnormalities, and automatically trigger the retry mechanism or switch the backup node when an abnormal node is detected, and at the same time issue an alarm, specifically, feedback fault information through the abnormal alarm interface to ensure the stable operation of the process.

[0073] (52) The corresponding JSON-formatted node configuration file is retrieved and run according to the scheduling instructions via the intelligent dynamic scheduling engine to obtain the algorithm processing results and visualization image data.

[0074] In addition, the intelligent dynamic scheduling engine supports dynamic adjustment of the process. During operation, it can modify the node combination and parameter configuration in real time according to the instructions or data feedback from the upper layer application without stopping the entire process, thus adapting to the needs of highly dynamic scenarios.

[0075] This application also provides examples using "template matching + ROI correction + color matching" as an application scenario.

[0076] This application provides, as follows: Figure 3 The input image and configuration shown are written in a config.json file, which configures each operator node. Global I / O configuration is performed: each configuration has inherent fields, as shown in Table 1 below.

[0077] Table 1

[0078] Template matching node configuration: Among them, NodeName, NodeSwitch, and NodeType are inherent fields of each core node. NodeSwitch can turn the node on or off without affecting the flow of node data in the entire scene. As shown in Table 2 below.

[0079] Table 2

[0080] Trigger node configuration: Type: 0 indicates image tiling, 1 indicates image correction. See Table 3 below.

[0081] Table 3

[0082] The color matching node configuration is shown in Table 4 below.

[0083] Table 4

[0084] Each node outputs JSON information: The template matching node outputs matching angle, matching center point, and matching feature light information. Specifically, it outputs this information in code form, such as a matching angle of -0.25, a matching center point of (1274.0, 1846.0), and matching feature light information.

[0085] The trigger node output includes the coordinate information of the corrected ROI (Region of Interest): infer_flag (represents the inference state of the operator node): 0 infer_time (representing the inference time of the operator node): 0.0015790000325068831 Rois (representing a set of regions of interest): LF_DECORATIVE_COLOR (representing the color measurement point of the front left trim strip): [154,251], [225,288] LR_DECORATIVE_COLOR (indicates the color of the rear left decorative strip): [373,250], [447,287] Where [[154,251], [225,288]] represent the pixel coordinates of the top left and bottom right corners of the ROI box.

[0086] The color matching node output includes the minimum similarity score, the minimum similarity template, the ROI coordinates, and similarity information for all templates. A sample code example is shown below: LF_DECORATIVE_COLOR (represents the color measurement point of the front left trim strip): minSimilarity (minimum similarity, representing the similarity between the image and the template color matching result; the smaller the value, the more similar the image): 2.7881298065185547 minTempl (minimum template, representing the template color with the lowest similarity): F16-5500210CA (represents the part code for this color, without actual meaning, a part name given by the user). Rois (representing the set of regions of interest): [154, 251], [225, 288] Similarities (a list of similarities, representing the similarity to each template color): F16-5500210CA: 2.7881298065185547 F28-5500210CA:11.936810493469238 LR_DECORATIVE_COLOR (indicates the color of the rear left decorative strip): minSimilarity: 18.049560546875 minTempl: F16-5500230CA Rois: [373,250], [447,287] Similarities: F16-5500230CA:18.049560546875 F16-5500230CB:72.82110595703125 infer_flag: 0 infer_time: 0.003275000024586916.

[0087] Each node outputs a visual image, such as Figure 4 , Figure 5 , Figure 6 As shown. Among them, Figure 4 The red number 91.626678 marked in the image represents the similarity score of the template matching node. Figure 6 The areas marked with green boxes have the following labels: F16-5500210CA: 2.7881298065185547, F16-5500230CA: 18.049560546875.

[0088] In summary, this application provides the following technical means.

[0089] Two-level node architecture design: The traditional algorithm is broken down into core nodes and scenario nodes. By ensuring the core nodes are independent and loosely coupled, and allowing for flexible combination of scenario nodes, this design replaces the traditional redundant hierarchical architecture. This enables efficient algorithm combination and custom extensions, breaking the limitations of the rigid architecture of existing SDKs. Scenario nodes are composed of core nodes and support free secondary editing. Their combination logic, defined through configuration files, can be directly implemented as a complete business algorithm flow without additional hierarchical encapsulation or call adaptation. This adapts to the rapid implementation needs of different business scenarios, overcoming the limitation of existing SDK modules requiring secondary development and encapsulation after combination.

[0090] The node standardization specification system encompasses standardized definitions across all dimensions of input / output, parameter configuration, and interfaces, as well as standardized encapsulation tools for third-party algorithms. This enables seamless inter-node integration and rapid access to third-party algorithms, addressing the insufficient scalability of existing technologies. Based on the standardized input / output specifications, automatic data format conversion logic is designed between different algorithm nodes. This achieves seamless data connection between different types of nodes, such as camera calibration operators and image distortion correction operators, resolving the issue of fixed data flow formats and the need for manual adaptation between existing SDK modules.

[0091] Visual drag-and-drop orchestration and debugging: It integrates a visual interface and step-by-step debugging function, which can complete the orchestration of algorithm flow and fault location without writing code, significantly reducing the threshold for use and solving the pain point of poor usability of existing technologies.

[0092] The scheduling engine collaborates with the unified interface: Centered on the unified interface `sbt::flow::process_SBT_FLOW_ALG`, it combines the dependency resolution, load balancing, and fault tolerance capabilities of the dynamic scheduling engine to adapt to single / multi-node call scenarios. Simultaneously, standardized input / output parameters (including JSON node configuration and dual-key output) ensure efficient and stable process operation, unlike existing SDKs with fixed scheduling logic and distributed interface designs. The unified interface's output parameters feature two fixed keys: `output` (algorithm processing result) and `visual` (visual image data), enabling synchronous output of algorithm results and process visualization. This addresses both business implementation and debugging / optimization needs, differing from existing SDKs that only return processing results.

[0093] Full lifecycle management of node resource pool: A centralized management pool that supports the addition, deletion, updating and querying of core nodes and scenario nodes, realizing standardized control and batch maintenance of algorithm nodes, while providing basic support for the coexistence of multiple version algorithms and node iterative upgrades. Unlike the design of existing SDKs that do not have unified module management, this reduces maintenance costs.

[0094] Disruption-free data flow design for node switching: Configure NodeSwitch inherent fields for all core nodes to support independent opening / closing of nodes, and the state adjustment of a single node will not affect the overall data flow of the entire scene nodes, improving the flexibility of algorithm flow orchestration and the convenience of debugging.

[0095] Based on the same inventive concept, this application also provides a system. The solution provided by this system is similar to the solution described in the above method. Therefore, the specific limitations of one or more system embodiments provided below can be found in the limitations of the method above, and will not be repeated here.

[0096] In one exemplary embodiment, a multi-scenario adaptation system based on node-based coupling with traditional algorithm standard SDKs is provided, including a node architecture design module, a node standardization definition module, a visual orchestration module, a dynamic scheduling module, and an interface adaptation module.

[0097] The node architecture design module is used to perform node-based mapping and encapsulation of algorithm operators for various traditional algorithms, establish a two-level layering of core nodes and scenario nodes, and build a node resource pool to store and manage all nodes.

[0098] The node standardization definition module is used to standardize the input and output, parameter configuration, and interaction interface of all nodes in the node resource pool. After standardizing the interaction interface in all dimensions, at least a preset unified SDK external call interface is obtained.

[0099] The visual orchestration module is used to configure parameters and generate node-based configuration files in JSON format through a visual drag-and-drop process orchestration and debugging mechanism based on a node resource pool defined in a full-dimensional standardized manner.

[0100] The interface adaptation module is used to call the interface externally through the preset unified SDK, receive the call request data of the target scenario, parse and convert it to generate the corresponding scheduling instructions.

[0101] The dynamic scheduling module is used to retrieve and run the corresponding JSON-formatted node configuration file according to the scheduling instructions, obtain the algorithm processing results and visualization image data, and then respond and feed back the results after encapsulating the response of the external call interface through the preset unified SDK.

[0102] In this system, the node architecture design module completes the layered design of core nodes and scene nodes, the node-based encapsulation of algorithm operators, and builds a node resource pool to achieve centralized storage and basic management of nodes, resulting in a standardized node architecture system. The node standardization definition module, based on the established node architecture, performs comprehensive standardization definitions of input / output, parameter configuration, and interaction interfaces for all core nodes and scene nodes. Simultaneously, it uses encapsulation tools to complete the node-based adaptation of third-party algorithms and incorporate them into the node resource pool. The visual orchestration module, based on the standardized node resource pool, provides users with no-code drag-and-drop process orchestration and parameter configuration capabilities, generating JSON-formatted node configuration files. The interface adaptation module receives call requests and configuration files from the upper-layer application, performs request parsing and data conversion, and then sends scheduling instructions to the dynamic scheduling module. The dynamic scheduling module parses node dependencies according to the configuration file, performs resource allocation and process scheduling, drives the collaborative operation of each node, and sends the results back to the interface adaptation module, which encapsulates the response and feeds it back to the upper-layer application. These modules are layered and work collaboratively, ultimately achieving flexible adaptation of traditional algorithm SDKs to multiple scenarios.

[0103] Compared with existing technologies, this application has significant advantages, with each beneficial effect corresponding to a specific technical point, achieving a precise breakthrough.

[0104] (1) Enhance customization capabilities to adapt to diverse and personalized scenarios. This application achieves fine-grained algorithm decomposition through a node architecture, and the independent operation characteristics of core nodes and scenario nodes support free combination. A drag-and-drop process editing is provided through visual programming, which can flexibly adjust the node order and insert custom logic. The standardized definition of nodes supports the customization of parameter validation rules to meet personalized parameter configuration needs.

[0105] This application breaks through the limitations of existing SDK customization, supporting full-dimensional customization of algorithm flow, parameter configuration, and function combination. It can accurately adapt to the personalized needs of different industries and scenarios, and can be flexibly adjusted without modifying the SDK source code.

[0106] (2) Enhance scalability and reduce the cost of algorithm iteration and third-party integration. This application sets up a node resource pool to support the addition, updating, and deletion of core nodes and scene nodes. The loose coupling design of core nodes can avoid interference from new functions to existing modules, without the need for overall redeployment. Standardized node encapsulation tools provide a fast encapsulation path for third-party algorithms without modifying the underlying SDK code, reducing the difficulty of integration and adaptation costs.

[0107] This application enables rapid algorithm iteration and functional expansion, supports low-cost access to third-party algorithms, and significantly improves the SDK's adaptability and lifecycle.

[0108] (3) Improve usability and increase development and debugging efficiency. This application replaces code writing and complex configuration with drag-and-drop operation, which is intuitive and easy to understand. The preview and debugging area supports step-by-step operation and breakpoint debugging, and can view intermediate results and running status in real time, quickly locate faults, and greatly improve debugging efficiency.

[0109] This application lowers the barrier to entry for using the SDK, allowing non-professional algorithm developers to get started quickly, while simplifying the debugging process, shortening the development cycle, and reducing development costs.

[0110] (4) Reduce module coupling and maintenance costs. This application completely breaks the high coupling problem of traditional modules by establishing an independent operating environment for core nodes. Modifying a single node will not affect the operation of other nodes. Standardized node definitions ensure unified node interfaces and data formats, reducing compatibility issues during version iterations. A node resource pool is constructed to achieve centralized management of core nodes and scenario nodes, facilitating unified module maintenance and version control.

[0111] This application implements a loosely coupled design between nodes, simplifies the maintenance process, reduces the maintenance cost of module iteration and version compatibility, and improves the stability of SDK operation.

[0112] (5) Optimize operating efficiency and ensure process stability. This application optimizes resource allocation and reduces running time through dynamic scheduling dependency resolution and load balancing functions; abnormal retry and backup node switching mechanisms can quickly respond to node failures, avoid process interruption, and improve stability. This application improves the overall operating efficiency of the algorithm process, while also having fault tolerance capabilities to ensure stable operation in complex scenarios.

[0113] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 7 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs.

[0114] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0115] In one exemplary embodiment, a computer device is also provided, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the above-described method embodiments.

[0116] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0117] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0118] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0119] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0120] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0121] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible 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.

[0122] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A multi-scenario adaptation method based on coupling of nodalization with legacy algorithm standards SDK, characterized in that, The method includes: For various traditional algorithms, we perform node-based mapping and encapsulation of algorithm operators, two-level hierarchical structure of core nodes and scene nodes, and build a node resource pool to store and manage all nodes. The input / output, parameter configuration, and interaction interface of all nodes in the node resource pool are standardized in all dimensions; wherein, after the interaction interface is standardized in all dimensions, at least a preset unified SDK external call interface is obtained; Based on a node resource pool defined by full-dimensional standardization, parameters are configured and node-based configuration files in JSON format are generated through a visual drag-and-drop process orchestration and debugging mechanism. The system uses the pre-defined unified SDK to call external interfaces, receives call request data from the target scenario, parses and transforms it to generate corresponding scheduling instructions; According to the scheduling instructions, the corresponding JSON-formatted node configuration file is retrieved and run to obtain the algorithm processing results and visualization image data. Then, the response is encapsulated and fed back through the external call interface of the preset unified SDK.

2. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 1, characterized in that, For various traditional algorithms, we perform node-based mapping and encapsulation of algorithm operators, establish a two-level hierarchy of core nodes and scene nodes, and build a node resource pool to store and manage all nodes, including: By using algorithm operator node mapping and encapsulation, a class of traditional algorithms can be encapsulated into an operator node; Based on the multiple operator nodes, a two-level architecture of core node-scene node is constructed; A node resource pool is built to store and manage all core nodes and scene nodes covered in the core node-scene node two-level architecture, and to support the addition, deletion, updating and querying of core nodes and scene nodes.

3. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 2, characterized in that, Based on the multiple operator nodes, a two-level architecture of core node-scene node is constructed, including: Each of the aforementioned operator nodes is taken as a core node, and each core node encapsulates the logic, parameter configuration, and input / output interfaces of the corresponding algorithm; the algorithm operators corresponding to the core nodes include: machine vision operators, data processing operators, and detection operators; Multiple core nodes are combined according to preset rules to obtain scene nodes adapted to the corresponding business scenarios; the scene nodes support secondary editing and modification.

4. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 1, characterized in that, The standardization of input / output, parameter configuration, and interaction interfaces for all nodes within the node resource pool is performed across all dimensions, including: Regarding input and output, the data format and adaptation rules of any of the nodes are defined, the data conversion rules between different nodes are defined, and the correspondence between the input and output data structures of the nodes and the parameters of the preset unified SDK external call interface is determined. In terms of parameter configuration, a unified parameter description format, adjustable range definition and default value are set for each core node, and user-defined parameter verification rules are defined. Regarding the interaction interface, define the interaction interface between nodes and the preset unified SDK external call interface for external calls.

5. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 1, characterized in that, Based on a node resource pool defined in all dimensions, a visual drag-and-drop process orchestration and debugging mechanism is used to configure parameters and generate node-based configuration files in JSON format, including: A visual interactive interface is constructed; the visual interactive interface includes a visual node resource display area, a process editing area, a parameter configuration area, and a preview and debugging area; The node resource display area showcases all nodes in the fully standardized node resource pool, and labels and displays the function, parameters, and applicable scenarios of each node. The process editing area allows users to combine nodes and arrange the flow sequence by dragging and dropping nodes and connecting them. It also allows users to insert custom logic nodes. The parameter configuration area allows users to configure and adjust parameters for each node, and displays the effect of parameter adjustments in real time. The preview and debugging area supports step-by-step execution and breakpoint debugging of the sequential process of nodes after process editing and parameter configuration, and displays the running status, data flow process and intermediate results of each node. It also supports fault node location. After the user confirms the debugging is completed, a node-based configuration file in JSON format is generated.

6. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 1, characterized in that, The pre-defined unified SDK external call interface is as follows: sbt::flow::process_SBT_FLOW_ALG(input,outputs); Wherein, input refers to the interface input, and outputs refers to the interface output; The interface input is speed::SVariantMap input, which is used to receive and store the data to be processed corresponding to the call request data and the corresponding JSON-formatted node configuration file; The interface output is std::map<int, speed::SVariantMap> The outputs function returns the result of a single node when the core node is invoked, and the results of all participating nodes when the scene node is invoked. The results of each node include the algorithm processing results and the visualization image data.

7. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 1, characterized in that, According to the scheduling instructions, the corresponding JSON-formatted node configuration file is retrieved and run to obtain the algorithm processing results and visualized image data, including: An intelligent dynamic scheduling engine is established; the intelligent dynamic scheduling engine is used to: automatically identify the dependencies between nodes and optimize the calling order of nodes; allocate computing resources according to the running time and resource consumption of each node; and automatically trigger a retry mechanism or switch to a backup node when an abnormal node operation is detected, while issuing an alarm. The intelligent dynamic scheduling engine retrieves and runs the corresponding JSON-formatted node configuration file according to the scheduling instructions to obtain the algorithm processing results and visualized image data.

8. The multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in claim 4, characterized in that, The standardization definition of input / output, parameter configuration, and interaction interfaces for all nodes in the node resource pool also includes: Call upon third-party algorithm standardization and encapsulation tools; Upon receiving a third-party algorithm, the third-party algorithm standardization and encapsulation tool is used to perform node-based adaptation and full-dimensional standardization definition of the third-party algorithm, and then incorporate it into the node resource pool.

9. A multi-scenario adaptation system based on node-based architecture coupled with traditional algorithm standard SDKs, characterized in that, The system includes: The node architecture design module is used to perform node-based mapping and encapsulation of algorithm operators for various traditional algorithms, two-level layering of core nodes and scene nodes, and to build a node resource pool to store and manage all nodes. The node standardization definition module is used to standardize the input and output, parameter configuration, and interaction interface of all nodes in the node resource pool. After standardizing the interaction interface in all dimensions, at least a preset unified SDK external call interface is obtained. The visual orchestration module is used to configure parameters and generate node-based configuration files in JSON format through a visual drag-and-drop process orchestration and debugging mechanism based on a node resource pool defined in full dimensions. The interface adaptation module is used to call the interface externally through the preset unified SDK, receive the call request data of the target scenario, parse and convert it to generate the corresponding scheduling instructions; The dynamic scheduling module is used to retrieve and run the corresponding JSON-formatted node configuration file according to the scheduling instructions, obtain the algorithm processing results and visualization image data, and then respond and feed back the results after encapsulating the response of the external call interface through the preset unified SDK.

10. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the multi-scenario adaptation method based on node-based coupling with traditional algorithm standard SDKs as described in any one of claims 1-8.

Images