Body-aware data processing method and system, storage medium, program product

Abstract

Embodiments of the present application provide a body intelligence data processing method and system, a storage medium and a program product. The body intelligence data processing method comprises: receiving process definition information for defining a body intelligence data processing process; generating a process instance based on the process definition information; determining execution environment information corresponding to at least one sub-process in the process instance, and scheduling and executing the sub-process according to the execution environment information corresponding to the sub-process, to obtain execution state information and a data processing result corresponding to at least part of the sub-process; and in the case that the execution state information and / or the data processing result meet a preset triggering condition, triggering execution of at least one sub-process in the process instance which has a dependency relationship with the corresponding sub-process in the process definition information, based on the execution state information and / or the data processing result. Embodiments of the present application can realize automatic collaborative execution of a body intelligence data processing process in multiple execution environments.

Description

Technical Field

[0001] This application relates to the fields of embodied intelligence and resource scheduling technology, and in particular to embodied intelligence data processing methods and systems, storage media, and program products. Background Technology

[0002] With the rapid development of artificial intelligence and robotics technologies, embodied intelligence has gradually become an important research direction in the field of intelligent robotics. Embodied intelligent systems typically enable robots to complete complex tasks in real-world environments by integrating perception, decision-making, and execution capabilities. In the application of embodied intelligence, the development and deployment of models and algorithms usually involve multiple stages, including data acquisition, data processing, model training, model evaluation, simulation verification, model deployment, real-machine inference, and closed-loop iteration. However, in practical engineering applications, embodied intelligent systems often need to operate in complex and dynamic environments, making it difficult to achieve unified orchestration of data processing flows across execution environments.

[0003] Based on this, embodiments of this application provide a method and system for embodied intelligent data processing, a storage medium, and a program product to improve related technologies. Summary of the Invention

[0004] The purpose of this application is to provide a method and system for embodied intelligent data processing, a storage medium, and a program product, so as to realize the automated collaborative execution of embodied intelligent data processing flow in multiple execution environments, thereby improving overall processing efficiency, process controllability, and operational stability.

[0005] In a first aspect, embodiments of this application provide an embodied intelligent data processing method, the method comprising: receiving process definition information for defining an embodied intelligent data processing flow; the process definition information being used to characterize multiple sub-flows and the dependencies between the multiple sub-flows; generating a process instance based on the process definition information; for at least one sub-flow in the process instance, determining the execution environment information corresponding to the sub-flow, and scheduling and executing the sub-flow according to the execution environment information corresponding to the sub-flow to obtain execution status information and data processing results corresponding to at least some sub-flows; the execution environment information being used to indicate that the sub-flow is executed in any of at least two types of execution environments; and, when the execution status information and / or the data processing results meet preset triggering conditions, triggering the execution of at least one sub-flow in the process instance that has a dependency relationship with the corresponding sub-flow in the process definition information based on the execution status information and / or the data processing results.

[0006] In some embodiments, the at least two types of execution environments include a cloud execution environment and an edge execution environment. The cloud execution environment is used to execute sub-processes related to at least one of model training, model evaluation, and data processing, and the edge execution environment is used to execute sub-processes related to at least one of model deployment, real-device inference, real-device evaluation, and data sampling.

[0007] In some embodiments, the process definition information processes the embodied intelligent data processing process into a workflow structure; the plurality of sub-processes serve as workflow nodes that can be independently scheduled and executed, and the dependencies between the plurality of sub-processes are defined in the workflow structure.

[0008] In some embodiments, the dependency relationship is used to indicate at least one of serial execution relationship, parallel execution relationship, and batch execution relationship among the plurality of subprocesses.

[0009] In some embodiments, the execution environment information is used to indicate whether the same subprocess is executed in parallel or in batches in multiple execution environments.

[0010] In some embodiments, the preset triggering conditions include at least one of the following: at least some sub-processes are executed successfully; at least some sub-processes fail to execute; the data processing results meet preset numerical conditions; and a preset number of data processing results are generated.

[0011] In some embodiments, scheduling and executing the subprocess according to the execution environment information corresponding to the subprocess includes: when the execution environment information indicates that the subprocess is executed in an edge execution environment, determining at least one target execution environment for executing the subprocess from multiple edge execution environments based on preset target selection conditions; and scheduling and executing the subprocess in each of the at least one target execution environments, or coordinating the scheduling and execution of the subprocess.

[0012] In some embodiments, the target selection criteria are used to indicate at least one of the following: area information, device type, device capability label, device health status, number of online devices, network status, energy consumption constraints, and task priority strategy.

[0013] In some embodiments, the process of acquiring the edge execution environment includes: dividing edge resources into multiple edge work pools based on preset sharding rules; each edge work pool serves as an edge execution environment; wherein each edge work pool is used to represent an edge cluster or a specified resource domain within an edge cluster.

[0014] In some embodiments, the method further includes: performing statistical analysis on the execution status information of sub-processes from different execution environments to maintain the instance execution status information of the process instance.

[0015] In some embodiments, the process definition information further includes execution control configuration information for limiting the execution scope of sub-processes, wherein the execution control configuration information is used to indicate that only any consecutive sub-process segments or a single sub-process in the process instance are scheduled and executed; the method further includes: in the event of detecting an execution abnormality of the sub-process, determining updated execution control configuration information based on the execution status information corresponding to the sub-process; and performing at least one processing operation on the process instance based on the updated execution control configuration information; wherein the processing operation includes at least one of retry, rollback, and compensation.

[0016] Secondly, embodiments of this application provide an embodied intelligent data processing system, comprising: a receiving module for receiving process definition information for defining an embodied intelligent data processing flow; the process definition information characterizes multiple sub-flows and the dependencies between the multiple sub-flows; a generating module for generating a process instance based on the process definition information; an execution module for determining execution environment information corresponding to at least one sub-flow in the process instance, and scheduling and executing the sub-flow according to the execution environment information corresponding to the sub-flow to obtain execution status information and data processing results corresponding to at least some sub-flows; the execution environment information indicates that the sub-flow is executed in any of at least two types of execution environments; and a triggering module for triggering the execution of at least one sub-flow in the process instance that has a dependency relationship with the corresponding sub-flow in the process definition information, based on the execution status information and / or the data processing results, when the execution status information and / or the data processing results meet a preset triggering condition.

[0017] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the above-described embodied intelligent data processing methods.

[0018] Fourthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of any of the above-described embodied intelligent data processing methods.

[0019] This application provides an embodied intelligent data processing method and system, storage medium, and program product. By receiving and parsing process definition information used to define the embodied intelligent data processing flow, the complex data processing process is broken down into multiple sub-flows with clear dependencies. Based on execution environment information, each sub-flow is scheduled and executed, achieving unified management and collaborative operation of sub-flows under different execution environments. When the execution status information and / or data processing results meet preset trigger conditions, subsequent sub-flows with dependencies on the corresponding sub-flows are automatically triggered, enabling process instances to dynamically advance based on actual execution results, reducing manual intervention and process fragmentation. This application addresses the problems of long data processing flow chains, diverse execution environments, and complex dependencies between sub-flows that are difficult to automatically connect in embodied intelligent data processing systems. It adopts a unified orchestration and triggering mechanism driven by process definition information and execution status, thereby achieving automated collaborative execution of the embodied intelligent data processing flow in multiple execution environments, improving overall processing efficiency, process controllability, and operational stability. Attached Figure Description

[0020] The embodiments of this application are further described below with reference to the accompanying drawings and specific implementation details.

[0021] Figure 1 This is a flowchart illustrating an embodied intelligence data processing method provided in an embodiment of this application.

[0022] Figure 2 A schematic diagram of an embodied intelligent data processing architecture provided in an embodiment of this application is shown.

[0023] Figure 3 This is a structural block diagram of an embodied intelligent data processing system provided in an embodiment of this application.

[0024] Figure 4 This is a structural block diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] 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 a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the embodiments of this application.

[0026] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0027] In the field of embodied intelligence, the entire lifecycle of models and algorithms can include multiple stages such as data collection and cleaning, model training, model evaluation, system integration and construction, model deployment and inference, and online closed-loop iteration. These stages can constitute a complete edge-cloud collaborative processing link, and there are strong dependencies between the stages. The overall iteration cycle is usually measured in days or longer.

[0028] In related technologies, to support the large-scale engineering deployment of embodied intelligent systems, the industry typically employs cloud-native technologies (such as Kubernetes) to manage computing resources and task execution processes. For example, cloud computing power clusters based on container orchestration technology are used to uniformly schedule model training, model evaluation, and data processing tasks; simultaneously, edge access architectures are used to manage the access of robotic devices, sensor nodes, or real-device testing platforms to support autonomous operation in weak network environments and cloud-edge security isolation, thereby initially achieving unified management of large-scale robotic device clusters.

[0029] However, even with the aforementioned edge-cloud access and autonomy capabilities, embodied intelligence systems still struggle to effectively address the unified task orchestration and resource scheduling challenges across cloud and edge clusters. This is primarily because the cloud and edge environments differ significantly in workload types, resource constraints, and scheduling objectives. Furthermore, embodied intelligence tasks typically operate in an edge-cloud collaborative pipeline format. For instance, after cloud-based model training, it often triggers canary deployments and real-device verification on edge devices, while high-value operational data collected by edge devices needs to be transmitted back to the cloud for model retraining and re-evaluation. Without a unified orchestration and scheduling mechanism, the system typically suffers from the following problems.

[0030] First, the task chain is prone to fragmentation. In related systems, cloud training and evaluation processes and edge deployment and execution processes are usually handled by different management platforms. Task triggering relies on manual intervention or script splicing, and there is a lack of a unified dependency management mechanism, process status management mechanism, and anomaly recovery mechanism. This results in poor observability, traceability, and reproducibility of the overall process, and it is also highly sensitive to anomaly handling and retry operations.

[0031] Secondly, there is a fragmentation problem in the resource view. Cloud computing resources typically prioritize GPUs (Graphics Processing Units), CPUs (Central Processing Units), or storage resources for scheduling, while edge resources involve various operational constraints such as robot computing power, battery status, device temperature, geographical location, available sensor combinations, and network status. Related scheduling mechanisms struggle to comprehensively evaluate edge and cloud resources under a unified resource model, resulting in scheduling strategies often only achieving local optimization within a single cluster, failing to improve overall resource utilization efficiency.

[0032] Secondly, cross-cluster scheduling lacks unified semantics and consistency guarantees. When edge-cloud tasks migrate and execute between multiple clusters, they often face problems such as inconsistent task identity mapping relationships, difficulties in synchronizing execution states, difficulty in guaranteeing idempotent execution, and complex permission boundary control. Especially in weak network or offline operation scenarios, the lack of a reliable alignment mechanism between edge task execution records and cloud scheduling states leads to low correctness and maintainability of cross-cluster task orchestration.

[0033] Furthermore, existing scheduling mechanisms struggle to express the complex scheduling objectives in embodied intelligence scenarios. Embodied intelligence tasks not only require consideration of computing resources but also real-world operational constraints, such as task area limitations, device health status, energy consumption constraints, temperature rise limits, time window limits, payload capacity, and sensor combination capabilities. Simultaneously, they must meet business strategy requirements regarding canary deployment ratio control, task priority strategies, task preemption mechanisms, and cost-latency balance strategies. Scheduling solutions tailored to either the cloud or edge typically fail to express the global scheduling objectives of edge-cloud collaboration, leading to low deployment and verification efficiency and long online closed-loop iteration cycles.

[0034] Therefore, beyond the basic capabilities of connecting relevant robots to cloud-native control platforms, supporting autonomous operation in weak network conditions, and ensuring secure cloud-edge isolation, there is still a pressing need for a technical solution that enables unified resource orchestration and task scheduling across cloud and edge clusters. This solution requires building a unified task model, dependency model, and process state management mechanism at the task modeling level; forming a consistent resource abstraction model and constraint expression mechanism between the edge and cloud at the resource management level; and achieving cross-cluster task routing, scheduling decisions, execution state aggregation, and fault tolerance recovery capabilities at the execution control level. This will support the automated and efficient operation of embodied intelligent models from training and deployment to online data closed-loop iteration.

[0035] See Figure 1 , Figure 1 This is a flowchart illustrating an embodied intelligence data processing method provided in an embodiment of this application.

[0036] To achieve automated collaborative execution of embodied intelligent data processing processes in multiple execution environments, and to improve overall processing efficiency, process controllability, and operational stability, this application provides an embodied intelligent data processing method, which includes steps S101 to S104.

[0037] Step S101: Receive process definition information for defining the embodied intelligent data processing process; the process definition information is used to characterize multiple sub-processes and the dependencies between the multiple sub-processes.

[0038] Step S102: Generate a process instance based on the process definition information.

[0039] Step S103: For at least one sub-process in the process instance, determine the execution environment information corresponding to the sub-process, and schedule and execute the sub-process according to the execution environment information corresponding to the sub-process to obtain execution status information and data processing results corresponding to at least some sub-processes; the execution environment information is used to indicate that the sub-process is executed in any of at least two types of execution environments.

[0040] Step S104: If the execution status information and / or the data processing result meet the preset triggering conditions, based on the execution status information and / or the data processing result, trigger the execution of at least one subprocess in the process instance that has a dependency relationship with the corresponding subprocess in the process definition information.

[0041] In some embodiments, the embodied intelligence data processing method can be executed by an embodied intelligence data processing system. The embodied intelligence data processing system is used to implement functions such as unified orchestration of the embodied intelligence data processing flow, task scheduling, and execution status management.

[0042] In some embodiments, the embodied intelligent data processing system can be implemented in software. Specifically, the embodied intelligent data processing system can be implemented through program modules deployed on servers, cloud computing nodes, or edge computing nodes. For example, the embodied intelligent data processing system may include software functional components such as workflow orchestration modules, task scheduling modules, state management modules, and execution control modules. By calling the processor to execute program instructions stored in memory, it can realize functions such as defining the embodied intelligent data processing flow, generating flow instances, scheduling and executing sub-flows, and controlling the triggering of execution states.

[0043] In some embodiments, the embodied intelligent data processing system can also be implemented in hardware. Specifically, the embodied intelligent data processing system can be implemented using dedicated computing devices, such as server devices, edge computing terminals, industrial control devices, or embedded control devices. The hardware devices may include hardware components such as processors, memory, communication interfaces, and input / output interfaces. Through the collaborative work of these hardware components, the embodied intelligent data processing system can complete task management and execution control of the embodied intelligent data processing flow.

[0044] In some embodiments, the embodied intelligent data processing system can also be implemented using a combination of hardware and software. Specifically, the embodied intelligent data processing system can be implemented by running a dedicated control program or scheduler on a general-purpose computing hardware device. The hardware device provides computing and data communication capabilities, while the software module implements functional controls such as workflow orchestration logic, execution environment scheduling logic, and execution state triggering logic, thereby enabling the execution of the embodied intelligent data processing method.

[0045] In some embodiments, the embodied intelligent data processing system can be deployed in a cloud execution environment, an edge execution environment, or a cloud-edge collaborative execution environment. For example, the embodied intelligent data processing system can be deployed in a cloud cluster to perform model training and data processing tasks, or it can be deployed in an edge node or robotic device to perform model deployment and real-device inference tasks, or it can achieve unified data processing flow management across execution environments through a cloud-edge collaborative architecture.

[0046] Embodied intelligence data processing methods refer to data processing approaches that encompass the entire process of model training, deployment, inference, evaluation, and data feedback within an embodied intelligence data processing system. Unlike data processing performed only in a single computing environment, this method involves the coupling between the model and the real physical environment, the execution platform, and perceptual feedback, encompassing a multi-stage, multi-role, and multi-execution environment data processing flow. For example, this embodied intelligence data processing method can be applied to collaborative scenarios of cloud-based training and edge-based real-device verification of robot models, as well as to model iteration scenarios where simulation environments and real devices operate in a hybrid manner.

[0047] Process definition information can be configuration or descriptive information used to describe the overall structure of an embodied intelligent data processing process. It characterizes the multiple sub-processes within the data processing process and the logical relationships between them. Process definition information can be implemented in the form of configuration files, structured data, or process description languages, and is used to clarify the execution order, dependencies, and triggering conditions of each sub-process. Through process definition information, complex data processing chains can be uniformly modeled before process execution, providing a basis for the generation and execution of subsequent process instances.

[0048] Subprocesses can be the basic execution units that constitute an embodied intelligent data processing flow, used to carry out specific data processing tasks or functional modules. Each subprocess can independently define its input data, processing logic, and output results, and can be scheduled and executed independently. As an example, subprocesses may include data cleaning subprocesses, model training subprocesses, model evaluation subprocesses, model deployment subprocesses, real-device inference subprocesses, or data sampling subprocesses, etc. By breaking down subprocesses, the implementation difficulty of complex processes can be reduced, and the flexibility and scalability of the processes can be improved.

[0049] Dependencies between sub-processes can be used to describe the sequential constraints or triggering relationships between different sub-processes in their execution logic. This dependency can indicate that the execution of one sub-process requires the execution result or status of another sub-process as a prerequisite. For example, a model training sub-process can be defined as dependent on the completion of a data processing sub-process, or a model deployment sub-process can be defined as dependent on a model evaluation sub-process meeting preset metrics. By explicitly defining dependencies between sub-processes, it can be ensured that process instances proceed in an orderly manner according to the expected logic during execution.

[0050] A process instance refers to a data processing process entity generated based on process definition information and used for actual execution. A process instance carries a specific data processing task and maintains the execution status and context information of each sub-process during its operation. Each process instance can correspond to a model iteration, a round of data processing, or a real-device verification task. By instantiating process definition information into process instances, abstract process structures can be transformed into executable runtime objects, thereby supporting the dynamic scheduling and execution of processes.

[0051] Execution environment information can be used to indicate the type of execution environment and its location for a sub-process. At a minimum, this information distinguishes whether a sub-process is running in a different type of execution environment, such as a cloud execution environment or an edge execution environment. For example, a cloud execution environment can be used to execute computationally intensive sub-processes such as model training, model evaluation, or large-scale data processing; an edge execution environment can be used to execute sub-processes that interact with real devices, such as model deployment, real-device inference, real-device evaluation, or online data sampling. By introducing execution environment information, flexible configuration and unified scheduling of the sub-process execution location can be achieved.

[0052] Scheduling and executing sub-processes refers to the process of allocating resources, arranging the execution order, and controlling the actual operation of sub-processes based on their corresponding execution environment information. During the scheduling phase, the embodied intelligent data processing system can select appropriate computing resources or execution nodes based on the execution environment information; during the execution phase, the system triggers the specific processing logic of the sub-process and monitors its running status. By combining scheduling and execution, automated operation of sub-processes can be achieved, providing execution feedback for subsequent process control.

[0053] Execution status information can be used to characterize the running status or result status of a subprocess during execution. Execution status information can include subprocess success or failure indicators, execution progress, exception information, resource usage, etc. By collecting and maintaining execution status information, the embodied intelligent data processing system can monitor the running status of each subprocess in a process instance in real time, and perform subsequent process control, exception handling, or trigger judgment based on the execution status information.

[0054] Data processing results refer to the output data or processing products generated after a sub-process is completed. Data processing results can include model parameters, evaluation metrics, inference results, sampled data, or intermediate processing data. Data processing results can not only serve as input data for subsequent sub-processes but can also be used to determine whether the process meets preset trigger conditions, thereby driving further execution of the process instance.

[0055] Preset trigger conditions can be used to define the conditions under which subsequent sub-processes within a process instance are triggered. Preset trigger conditions can be based on execution status information or data processing results, such as at least some sub-processes executing successfully, at least some sub-processes failing, data processing results meeting preset numerical conditions, or a preset number of data processing results being generated. By setting preset trigger conditions, event-driven execution of process instances can be achieved, allowing the process to dynamically adjust its execution path based on actual running conditions.

[0056] Triggering a subprocess that has a dependency relationship with a corresponding subprocess can refer to automatically starting the execution of at least one subprocess that has a logical dependency constraint on the subprocess when a preset triggering condition is met, based on the dependency relationships pre-established in the process definition information. This triggering process is controlled based on the dependency relationships in the process definition information, ensuring that the process instance follows the established process logic during operation, thereby achieving automatic connection and collaborative execution between multiple subprocesses.

[0057] In this embodiment, the embodied intelligent data processing flow is abstracted into flow definition information containing multiple sub-flows, and the dependencies between each sub-flow are explicitly described in the flow definition information to generate corresponding flow instances. During the execution of the flow instance, the execution environment information corresponding to at least one sub-flow is determined, enabling the sub-flow to be scheduled and executed in any of at least two different execution environments, thereby obtaining corresponding execution status information and data processing results. When the execution status information and / or the data processing results meet preset triggering conditions, the execution of at least one sub-flow that has a dependency relationship with the corresponding sub-flow is automatically triggered based on the dependencies pre-established in the flow definition information. In this way, the embodied intelligent data processing method can achieve unified orchestration and collaborative scheduling of sub-flows across different execution environments, and drive the flow instance to advance orderly among multiple sub-flows based on the execution status and processing results, thereby completing the automated operation of the embodied intelligent data processing flow.

[0058] This embodiment receives and parses process definition information used to define the embodied intelligent data processing flow, breaking down the complex data processing process into multiple sub-flows with clear dependencies. Based on execution environment information, it schedules and executes each sub-flow, achieving unified management and collaborative operation of sub-flows under different execution environments. When the execution status information and / or data processing results meet preset trigger conditions, it automatically triggers the execution of subsequent sub-flows that are dependent on the corresponding sub-flow (i.e., sub-flows whose execution status information and / or data processing results meet preset trigger conditions). This allows process instances to dynamically advance based on actual execution results, reducing manual intervention and process fragmentation. This embodiment addresses the problems of long data processing flow chains, diverse execution environments, and complex dependencies between sub-flows that are difficult to automatically connect in embodied intelligent data processing systems. It adopts a unified orchestration and triggering mechanism driven by process definition information and execution status, thereby achieving automated collaborative execution of the embodied intelligent data processing flow in multiple execution environments, improving overall processing efficiency, process controllability, and operational stability.

[0059] In some embodiments, the at least two types of execution environments may include cloud execution environments and edge execution environments.

[0060] In some embodiments, the cloud execution environment can be used to execute subprocesses related to at least one of model training, model evaluation, and data processing.

[0061] In some embodiments, the edge execution environment can be used to execute subprocesses related to at least one of model deployment, real-device inference, real-device evaluation, and data sampling.

[0062] In some embodiments, the model may include an embodied intelligence model. The embodied intelligence model can refer to a model used to support the embodied intelligence data processing system in information processing and behavioral control during perception, decision-making, and execution, and can be constructed based on machine learning, deep learning, or rule-based reasoning. As an example, the embodied intelligence model may include, but is not limited to, at least one of the following: a perception model for processing multimodal perception data, a decision model for generating control commands or action sequences, an evaluation model for predicting task progress or assessing execution effectiveness, and an end-to-end control model for jointly modeling the relationship between perception and action.

[0063] In some embodiments, the embodied intelligence model can be implemented using a neural network model, such as a convolutional neural network (CNN), a recurrent neural network (RNN), a Transformer architecture, or a combination thereof; it can also be implemented using a multi-model collaborative approach, such as deploying the perception model and the control model separately, or having the policy model and the value model operate collaboratively. The model can be trained, updated, or evaluated in a cloud execution environment, or deployed and inferred in an edge execution environment, to adapt to the operational needs of the embodied intelligence system at different stages and in different execution environments.

[0064] In some embodiments, the model is not limited to being implemented using a specific algorithm or network structure. It can be a model trained in a data-driven manner or a model constructed based on rules, physical models, or hybrid modeling methods.

[0065] An execution environment refers to the computing and execution platform used to host and run sub-processes, providing them with the necessary computing resources, operating conditions, and operating context. In embodied intelligent data processing systems, the execution environment is not limited to a single type of computing node but can be flexibly divided according to the functional attributes and operational requirements of the sub-processes. For example, the execution environment may include centralized computing environments, distributed computing environments, remote server environments, local device environments, or embedded device environments. This embodiment introduces the concept of an execution environment to decouple the execution location of sub-processes from the process logic, thereby supporting unified scheduling and management of sub-processes in different operating scenarios.

[0066] At least two execution environments refer to the ability to introduce multiple different types of execution environments within the same embodied intelligent data processing flow to support the execution needs of different sub-flows. By dividing the execution environment into at least two categories, it is possible to differentiate and coordinately control the execution location of sub-flows. For example, one type of execution environment can focus on high-computing-power, high-throughput data processing tasks, while another type can focus on execution tasks that interact with real physical devices. This multi-execution-environment design allows the embodied intelligent data processing flow to simultaneously consider computational efficiency and the feedback requirements of the real environment.

[0067] A cloud-based execution environment refers to an execution environment deployed on a cloud computing platform or a centralized computing cluster, possessing strong computing, storage, and parallel processing capabilities. Cloud-based execution environments are suitable for supporting sub-processes that require significant computing power and resource scale but do not directly rely on physical devices. For example, cloud-based execution environments can include public cloud platforms, private cloud clusters, data center server clusters, or cloud-native computing environments built on container or virtualization technologies. By deploying some sub-processes in a cloud-based execution environment, the overall efficiency of data processing and model computation can be improved.

[0068] A cloud-based execution environment can be used to execute sub-processes related to at least one of model training, model evaluation, and data processing. Specifically, the model training sub-process can be used to optimize the parameters of an embodied intelligence model based on training data; the model evaluation sub-process can be used to evaluate the performance and calculate metrics of the trained model; and the data processing sub-process can be used to perform pre-processing or intermediate operations such as data cleaning, feature extraction, and format conversion. Because these sub-processes typically involve significant computational demands and have low dependence on real-time physical feedback, they are well-suited for centralized execution in a cloud-based execution environment.

[0069] An edge execution environment refers to an execution environment deployed close to physical devices or embodied intelligent carriers, maintaining a relatively short physical or network distance from robots, sensors, or other execution terminals. Edge execution environments can be distributed across edge servers, edge computing nodes, the robot itself, or computing devices within a local network. By running subprocesses within an edge execution environment, data transmission latency can be reduced, and the system's responsiveness to changes in the real-world environment can be improved.

[0070] The edge execution environment can be used to execute sub-processes related to at least one of model deployment, real-device inference, real-device evaluation, and data sampling. Specifically, the model deployment sub-process can be used to distribute and load models generated or updated in the cloud onto edge devices; the real-device inference sub-process can be used to perform inference calculations on real sensor data based on the deployed model; the real-device evaluation sub-process can be used to verify model performance on real devices; and the data sampling sub-process can be used to collect data generated during real-world operation and transmit it back. By executing these sub-processes in the edge execution environment, a tight coupling between the embodied intelligent system and the real physical environment can be achieved.

[0071] In embodied intelligence data processing workflows, cloud-based execution environments and edge execution environments can form a collaborative relationship: the cloud-based execution environment focuses on centralized processing and computation of models and data, while the edge execution environment focuses on the operation, verification, and data acquisition of models in real physical environments. By configuring corresponding execution environments for different sub-processes in the process definition information and performing unified scheduling during the execution of process instances, the synergistic cooperation between cloud computing capabilities and edge real-time feedback capabilities can be achieved, thereby supporting the continuous iteration and closed-loop optimization of embodied intelligence models.

[0072] In some embodiments, the process definition information processes the embodied intelligent data processing process into a workflow structure. The plurality of sub-processes can serve as independently schedulable and executable workflow nodes, and the dependencies between the plurality of sub-processes are defined in the workflow structure.

[0073] Workflow structure refers to the organizational form of a data processing flow built based on process definition information. It abstracts the embodied intelligent data processing flow into a process network consisting of multiple workflow nodes and the connections between them. Workflow structure can be used to describe the execution order, parallel relationships, or conditional triggering relationships of each processing step in the process. As an example, workflow structure can be implemented using directed acyclic graphs, conditional flowcharts, or state machine models, enabling complex data processing flows to be expressed and managed in a structured manner.

[0074] A workflow node is a node entity within a workflow structure that represents a sub-process, mapping the sub-process to a specific location within the workflow structure. Sub-processes, as workflow nodes, can be independently scheduled and executed, maintaining their corresponding running state during execution. By abstracting sub-processes as workflow nodes, the embodied intelligent data processing system can perform scheduling control, status monitoring, and dependency management of sub-processes in a unified manner, thereby achieving modularity and scalability of the process.

[0075] Subprocesses can be independently scheduled and executed, meaning that each workflow node corresponding to a subprocess can be allocated execution resources and triggered to run independently without relying on other subprocesses running simultaneously. This feature enables embodied intelligent data processing systems to flexibly schedule different subprocesses according to actual operating conditions, such as executing some subprocesses in parallel, in batches, or with delayed execution. By supporting the independent scheduling and execution of subprocesses, the resource utilization efficiency and execution flexibility of embodied intelligent data processing workflows can be improved.

[0076] Defining dependencies between multiple sub-processes within a workflow structure is crucial. For example, a model evaluation sub-process might depend on the completion of a model training sub-process, or a model deployment sub-process might depend on the model evaluation results meeting preset conditions. By explicitly defining these dependencies within the workflow structure, it's possible to ensure that process instances proceed in an orderly manner according to the expected logic during execution.

[0077] The definition and control logic of dependencies can be used to constrain the triggering and execution of sub-processes within a workflow structure. During the execution of a workflow instance, the embodied intelligent data processing system, based on the pre-defined dependencies in the workflow definition information and combined with the execution status information or data processing results of the sub-processes, determines whether to allow the execution of subsequent sub-processes. Through this control logic, event- or state-driven workflow advancement can be achieved, reducing the disordered or repetitive execution of sub-processes in the embodied intelligent data processing workflow, thereby improving the controllability and stability of the overall workflow.

[0078] In some embodiments, the dependency relationship may be used to indicate at least one of serial execution relationship, parallel execution relationship, and batch execution relationship among the plurality of subprocesses.

[0079] In some embodiments, the execution environment information can be used to indicate whether the same subprocess is executed in parallel or in batches in multiple execution environments.

[0080] Dependencies can be used to define how different sub-processes are related in terms of time sequence, triggering conditions, or resource usage. Dependencies are not limited to a single form but can be flexibly configured according to business needs and system scheduling strategies.

[0081] Serial execution can be a type of dependency relationship, used to instruct multiple sub-processes to execute sequentially in a predetermined order. That is, the execution of a subsequent sub-process is only allowed after the current sub-process has been completed. Under serial execution, the execution of a subsequent sub-process typically depends on the execution status or data processing result of the preceding sub-process. This execution method is suitable for scenarios with clearly defined sequential logic or data dependencies among sub-processes, such as executing the model evaluation sub-process only after the model training sub-process has been completed.

[0082] Parallel execution relationships can be another form of dependency, indicating that multiple sub-processes can be executed simultaneously or nearly simultaneously under preset conditions. Under parallel execution relationships, different sub-processes can be scheduled to run in the same or different execution environments simultaneously, thereby improving overall processing efficiency. Parallel execution relationships are suitable for scenarios where there is no direct data dependency between multiple sub-processes, or whose processing logic is independent of each other, such as executing the same data processing or evaluation sub-processes in parallel on multiple data partitions.

[0083] Batch execution refers to a dependency relationship where sub-processes that could originally be executed in parallel or repeatedly are divided into multiple execution batches and executed sequentially according to a preset batch order. Batch execution allows for gradual scaling of the execution scale while ensuring the stability of the embedded intelligent data processing system. This execution method is suitable for scenarios requiring canary releases, phased verification, or resource constraints, such as deploying models in batches to edge devices of different regions or sizes for verification.

[0084] Execution environment information describes the execution location and scope of a subprocess. For example, it indicates at least the execution environment in which the subprocess runs and whether execution needs to be carried out in multiple environments. Execution environment information serves as a crucial basis for scheduling decisions, enabling the embodied intelligent data processing system to select the appropriate execution environment based on the functional characteristics and operational requirements of the subprocess during process instance execution. By configuring execution environment information, flexible control and unified management of the subprocess execution location can be achieved.

[0085] Parallel execution of the same subprocess in multiple execution environments refers to simultaneously scheduling the same subprocess instance to run in multiple different execution environments, so as to synchronously complete the same or equivalent data processing tasks in different execution environments. This execution method can be used to improve processing throughput or to compare and verify the same model or algorithm in different execution environments, such as executing real-device inference or evaluation subprocesses in parallel on multiple edge clusters.

[0086] Batch execution of the same sub-process in multiple execution environments refers to dividing the execution process of the same sub-process in multiple execution environments into multiple batches, and scheduling and executing them batch by batch according to a preset order. By executing in batches, the execution scope can be gradually expanded while controlling risks and resource consumption. This approach is suitable for scenarios such as canary deployment, phased verification, or gradual scaling-up execution in embodied intelligent data processing systems, and helps to improve the security and stability of system operation.

[0087] Dependency relationships and execution environment information can be used to comprehensively control the execution mode of sub-processes during the execution of a process instance. When determining whether a sub-process can be triggered, the embodied intelligent data processing system determines the execution sequence based on the dependencies set in the process definition information, and also determines the execution location and scale based on the execution environment information. Through this collaborative control logic, efficient scheduling and flexible execution of sub-processes in multiple execution environments can be achieved while ensuring the correctness of the process logic.

[0088] In some embodiments, scheduling and executing the subprocess according to the execution environment information corresponding to the subprocess may include: when the execution environment information indicates that the subprocess is executed in an edge execution environment, determining at least one target execution environment for executing the subprocess from multiple edge execution environments based on preset target selection conditions; and scheduling and executing the subprocess in each of the at least one target execution environments, or coordinating the scheduling and execution of the subprocess.

[0089] In this embodiment, the execution environment information may include an execution environment type identifier, an execution environment scope, or an execution strategy identifier, which is used to associate sub-processes with specific runtime environments. Through the execution environment information, the embodied intelligent data processing system can map sub-processes from the process logic layer to the actual execution carrier during the execution of a process instance, thereby decoupling the sub-process execution location from the process definition.

[0090] Target selection criteria can be constraints or strategy parameters used to filter target execution environments from multiple candidate edge execution environments. Target selection criteria can be configured from multiple dimensions, such as resource capabilities, operational status, and business strategies. As an example, target selection criteria may include region or site information, equipment type or model, equipment capability tags, equipment health status, online quantity thresholds, network status, energy consumption constraints, task priority strategies, or combinations thereof. Through target selection criteria, the embodied intelligent data processing system can select the execution environment that meets the needs of the current sub-process when edge resources are heterogeneous and distributed.

[0091] At least one target execution environment can refer to one or more execution environments determined from multiple edge execution environments based on target selection criteria, used to actually carry out the execution of the subprocess. At least one target execution environment can be a single edge execution environment or a collection of multiple edge execution environments. By introducing the concept of a target execution environment, the subprocess is no longer bound to a fixed execution node at the edge stage, but is dynamically located and executed according to real-time status and strategy.

[0092] Separate scheduling and execution of sub-processes refers to scheduling the same sub-process to each of the multiple target execution environments for independent execution, given multiple target execution environments. Each target execution environment operates independently during execution, and execution results and status can be collected and aggregated separately. This execution method is suitable for scenarios requiring parallel verification or comparison across multiple edge execution environments, such as simultaneously executing real-device inference or evaluation sub-processes in different regions or on different device types.

[0093] Coordinated scheduling and execution of sub-processes refers to the unified coordination and control of the execution of the same sub-process across multiple target execution environments, enabling these environments to form a collaborative relationship during execution. Coordinated scheduling and execution can include control logic such as task splitting, role allocation, execution synchronization, or result aggregation. For example, different sub-tasks of the same sub-process can be assigned to different edge execution environments, or the same verification or sampling task can be completed collaboratively across multiple edge execution environments. Through coordinated scheduling and execution, the overall execution efficiency and stability of complex sub-processes at the edge stage can be improved.

[0094] Scheduling control based on execution environment information is used to make decisions on the execution mode of sub-processes during the execution of process instances by comprehensively considering execution environment information and target selection conditions. When the execution environment information indicates that a sub-process is running in an edge execution environment, the embodied intelligent data processing system first triggers the evaluation process of target selection conditions to determine the target execution environment; then, according to the scheduling strategy, it selects to adopt the method of separate scheduling and execution or collaborative scheduling and execution, thereby realizing the flexible deployment and efficient operation of sub-processes in multiple edge execution environments.

[0095] In this embodiment, execution environment information is configured for sub-processes to indicate whether they run in an edge execution environment. When the execution environment information indicates that the sub-process is running in an edge execution environment, multiple edge execution environments are filtered based on preset target selection conditions to determine at least one target execution environment for executing the sub-process. The sub-processes are then scheduled for execution individually or collaboratively across multiple target execution environments based on the determined target execution environment. Through this method, the embodied intelligent data processing system can dynamically determine the specific edge execution location when a sub-process enters the edge stage, based on the target selection conditions, and control the deployment method of the sub-process in multiple edge execution environments according to the scheduling strategy. This allows the execution of sub-processes to have both flexible location selection capabilities and adaptability to different edge resource scales and operating strategies.

[0096] This embodiment introduces execution environment information during the sub-process scheduling phase. When a sub-process needs to run in an edge execution environment, it determines at least one target execution environment from multiple edge execution environments based on preset target selection conditions, thereby achieving dynamic selection of the sub-process execution location. By supporting separate or collaborative scheduling execution of the same sub-process in multiple target execution environments, sub-processes can be deployed in parallel or run collaboratively in multiple edge execution environments according to actual needs, thus improving the execution flexibility and resource utilization efficiency at the edge stage. This embodiment addresses the problems of dispersed edge resources, diverse execution environments, and difficulty in flexibly selecting and collaboratively executing sub-processes across multiple edge clusters in embodied intelligent data processing systems. It adopts an edge scheduling concept based on a combination of execution environment information and target selection conditions, thereby achieving dynamic scheduling and collaborative execution of sub-processes across multiple edge execution environments, improving the execution efficiency, scalability, and operational stability of embodied intelligent data processing processes at the edge stage.

[0097] In some embodiments, the target selection criteria may be used to indicate at least one of the following: area information, device type, device capability label, device health status, number of online devices, network status, energy consumption constraints, and task priority strategy.

[0098] Target selection criteria serve as the decision-making basis for filtering target execution environments from multiple candidate edge execution environments. They constrain and filter candidate execution environments from multiple dimensions, including resource capabilities, operational status, and business strategies. Target selection criteria can exist in the form of configuration parameters, rule sets, or strategy models, and are uniformly evaluated during the sub-process scheduling phase. By introducing target selection criteria, embodied intelligent data processing systems can reduce the static binding of sub-process execution environments, enabling dynamic location selection and strategic control of sub-process execution positions.

[0099] Regional information can be used to characterize the distribution of edge execution environments across geographical or logical regions. Regional information can include geographical regions, administrative regions, network regions, site identifiers, or business regions, and is used to constrain subprocesses to execute only within edge execution environments specified in the region. By introducing regional information, cross-regional data transmission latency can be reduced, and the requirements of embodied intelligent data processing systems in terms of deployment verification, partition management, or compliance can be met.

[0100] Device type can be used to differentiate between different categories of edge devices or execution terminals, reflecting differences in hardware architecture, functional capabilities, or application scenarios. For example, device type can include different models of robots, different categories of edge computing nodes, or different specifications of embedded devices. By selecting targets based on device type, it can be ensured that sub-processes execute only on devices with the corresponding functions or interfaces, thereby improving execution adaptability and success rate.

[0101] Device capability tags can be used to abstractly identify the capability characteristics of edge devices, reflecting their capabilities in terms of computing power, sensor configuration, actuator capabilities, or software environment. For example, a device capability tag might include computing power level, supported sensor types, supported control modes, or supported algorithm frameworks. Through device capability tags, embodied intelligent data processing systems can quickly determine whether a device meets the execution requirements of a sub-process, reducing the triggering of sub-processes in environments with mismatched capabilities.

[0102] Device health status can be used to characterize the operational stability and reliability of edge devices or execution environments. It can be assessed based on device uptime, fault records, resource usage, or self-test results. Device health status can be classified into different levels, such as normal, alarm, or abnormal. By using device health status as a target selection criterion, the scheduling of subprocesses to devices with potential failure risks can be reduced, thereby improving the overall operational stability of the embodied intelligent data processing system.

[0103] The number of online devices describes the number of devices currently online and available in a given edge execution environment or set of edge resources. This metric serves as an important indicator of whether the edge execution environment has sufficient execution capacity. By setting a threshold for the number of online devices, the embodied intelligent data processing system can ensure that subprocesses run in an edge execution environment with sufficient execution capacity, thereby meeting the needs of parallel execution, batch execution, or collaborative execution.

[0104] Network status can be used to characterize the quality of network connections between the edge execution environment and other components of an embodied intelligent data processing system. It can include metrics such as network bandwidth, latency, packet loss rate, and connection stability. Network status directly affects the efficiency and real-time performance of data interaction in subprocesses within the edge execution environment. By using network status as a selection criterion, execution environments with good network conditions can be prioritized, reducing the impact of communication anomalies on subprocess execution.

[0105] Energy constraints can be used to limit the energy consumption level of subprocesses in an edge execution environment. They can be configured based on device battery level, power consumption limits, or energy consumption policies. In embodied intelligent data processing systems, some edge devices may be limited by battery capacity or heat dissipation conditions. By setting energy constraints, high-load subprocesses can be reduced on energy-sensitive or low-power edge devices, thereby extending device uptime and improving system operational security.

[0106] Task prioritization strategies can be used to determine the execution order and resource allocation priority among multiple sub-processes or scheduling requests. Task prioritization strategies can be set based on at least one of business importance, urgency, time window, and resource consumption cost. By introducing task prioritization strategies, embodied intelligent data processing systems can prioritize the execution of critical sub-processes under resource constraints, thereby improving the overall scheduling efficiency and business responsiveness of embodied intelligent data processing workflows.

[0107] In some embodiments, to facilitate unified parsing and execution of the target selection conditions, a target selector may be introduced. The target selector is used to parse preset target selection conditions and, based on the parsing results, determine at least one target execution environment from multiple edge execution environments for executing the sub-process.

[0108] In some embodiments, the target selector can be implemented as an independent strategy module or logic unit. It can filter, sort or filter multiple edge execution environments based on at least one of regional information, device type, device capability label, device health status, number of online devices, network status, energy consumption constraints and task priority strategies, thereby outputting a set of target execution environments for executing the sub-process.

[0109] In some embodiments, the target selector may be implemented using a rule-matching method, a weighted scoring method, or a policy-based model. This embodiment does not limit the specific implementation form.

[0110] In some embodiments, the process of acquiring the edge execution environment may include: dividing edge resources into multiple edge work pools based on preset sharding rules; each edge work pool serves as an edge execution environment. Each edge work pool may be used to represent an edge cluster or a specified resource domain within an edge cluster.

[0111] Before or during the execution of a process instance, a set of edge execution environments can be constructed based on the organization and management rules of edge resources, making them available to the scheduling system. This transforms the dispersed underlying edge resources into execution environment objects that the scheduling layer can recognize and select, thereby supporting the location and scheduling decisions of sub-processes at the edge stage. Through this process, edge resources can be uniformly scheduled without directly understanding the details of the underlying devices.

[0112] Sharding rules are rules or strategies used to divide and organize edge resources, determining how edge resources are divided into multiple logical units. Sharding rules can be configured according to different management dimensions. For example, sharding rules can include sharding by geographical region, by site or campus, by tenant or business line, by security domain, by equipment type or model, or by resource capability level. Through sharding rules, edge resources can be logically formed into resource units with clear structures and well-defined boundaries.

[0113] Edge resources refer to a collection of various resources distributed at the edge to support the operation of an embodied intelligent data processing system. These resources may include computing resources, storage resources, network resources, and execution resources related to embodied intelligent devices. An edge work pool can be a logical resource unit formed by aggregating edge resources based on sharding rules, and it serves as the carrier entity for the edge execution environment.

[0114] Each edge work pool acts as an edge execution environment. This can refer to the scheduling layer directly mapping the edge work pool to a selectable and schedulable execution environment object. Through this mapping, scheduling decisions can be made based solely on the overall attributes of the edge work pool, without needing to know the specific edge resources contained within it. This design decouples the edge resource management layer from the scheduling execution layer.

[0115] An edge cluster refers to a collection of resources consisting of multiple edge nodes or edge devices, which can be centrally managed through a unified management platform. Edge clusters can have unified communication, scheduling, and security policies. For example, an edge cluster can be a collection of multiple edge servers and embodied intelligent devices (e.g., robots) deployed in the same site or campus. By mapping edge clusters to edge work pools, unified scheduling of sub-processes at the cluster level can be achieved.

[0116] A designated resource domain can refer to a subset of resources further subdivided within an edge cluster, used to define the scope of resource usage or management boundaries. Designated resource domains can be used to differentiate edge resources for different tenants, security levels, or business purposes. For example, a designated resource domain can be a namespace, a resource partition, or a security isolation zone within the edge cluster. By mapping designated resource domains to edge work pools, fine-grained resource management and scheduling control can be achieved within the same edge cluster.

[0117] In this embodiment, edge resources are logically divided based on preset sharding rules, organizing previously scattered or unevenly sized edge resources into multiple edge work pools. Each edge work pool is abstracted as an edge execution environment that can be uniformly scheduled and managed. Each edge work pool represents an edge cluster or a specific resource domain within an edge cluster, thus using the edge work pool as the smallest scheduling unit to select and schedule the edge execution location of sub-processes. Through this approach, edge resources are no longer exposed to the scheduling layer at the granularity of individual devices or nodes, but rather form a structured execution environment view through the work pool sharding mechanism, thereby supporting subsequent unified scheduling and execution control of sub-processes.

[0118] This embodiment introduces an edge work pool construction method based on sharding rules, dividing edge resources into multiple independently manageable edge work pools. Each edge work pool is scheduled as an edge execution environment. This enables unified abstraction and efficient management of edge execution environments in multi-edge cluster or multi-resource domain scenarios, thereby reducing scheduling complexity and improving the scalability and efficiency of edge resources. Addressing the challenges of large-scale, widely distributed, and diverse edge resources in embodied intelligent data processing systems, which are difficult to schedule and manage with uniform granularity, this embodiment employs a resource abstraction and execution environment construction mechanism based on edge work pool sharding. This achieves structured management and unified scheduling of edge resources, providing fundamental support for flexible location selection and efficient execution of subprocesses in multiple edge execution environments.

[0119] It should be noted that, in this embodiment, an embodied intelligent device can refer to an intelligent terminal device that possesses perception, decision-making, and execution capabilities and can operate in a real physical environment. An embodied intelligent device may include an actuator, sensor components, and a local computing unit, used to perform functions such as perceiving the environment, performing actions, and interacting with external systems. As an example, an embodied intelligent device may include various robots, mobile terminals, automated execution devices, or other intelligent agents with physical interaction capabilities.

[0120] Edge devices refer to devices deployed close to the data source or execution site, providing computing, control, or data processing capabilities at the edge. Edge devices can include the computing units within the embodied intelligent device itself, or edge computing nodes or edge servers independent of the embodied intelligent device. Compared to cloud devices, edge devices can offer lower network latency and stronger on-site responsiveness.

[0121] Edge nodes can be computing, storage, and network resource platforms (such as edge servers and gateways) located at the edge of the network, close to the data source or user end.

[0122] Edge resources refer to a collection of various resources provided by edge devices or edge nodes that can be scheduled and used. Edge resources may include computing resources, storage resources, network resources, and execution or sensing capabilities associated with embodied intelligent devices. Edge resources can be abstracted and managed in a logical form, rather than being directly equivalent to a specific device.

[0123] An edge cluster refers to a resource collection formed by unified management of multiple edge devices or resources, possessing a unified management, communication, and scheduling mechanism. Edge clusters can be organized by geographical region, site, network topology, or service domain. Through edge clustering, centralized management and collaborative scheduling of large-scale edge resources can be achieved.

[0124] An edge work pool can be a logical resource unit formed by dividing and aggregating edge clusters or edge resources based on preset sharding rules. Each edge work pool can contain one or more edge resources and be used as a basic execution unit. Edge work pools allow for controllable scheduling granularity even as the scale of edge resources continues to expand.

[0125] An edge execution environment refers to an execution platform used to host subprocesses running at the edge, which can be directly mapped from an edge worker pool. The edge execution environment provides a unified view of execution capabilities, enabling subprocesses to be scheduled and executed without needing to be aware of the underlying device details.

[0126] In this embodiment, edge devices, edge nodes, edge resources, edge clusters, edge worker pools, and edge execution environments are used to describe different hierarchical concepts on the edge side. Their specific meanings should be understood in context and do not constitute a limitation on specific implementation forms or hierarchical divisions.

[0127] In some embodiments, the method may further include: performing statistical analysis on the execution status information of sub-processes from different execution environments to maintain the instance execution status information of the process instance.

[0128] Execution status information from different execution environments can refer to the collection of execution status information generated by sub-processes distributed across different execution environments. In embodied intelligent data processing workflows, different sub-processes may run in cloud execution environments and edge execution environments respectively, with their execution status information scattered across multiple execution environments. By uniformly aggregating execution status information from different execution environments, the fragmentation of process instance states across multiple execution environments can be reduced, which helps to form a globally consistent view of process operation.

[0129] Statistical analysis refers to the process of summarizing, calculating, and judging the execution status information of multiple sub-processes from different execution environments. It is used to extract statistical results reflecting the overall process operation from scattered status data. Statistical analysis can include at least one of the following methods: counting statistics, proportional statistics, threshold judgment, status aggregation, and weighted analysis. Through statistical analysis, the local execution status of multiple sub-processes can be transformed into comprehensive status information at the process instance level.

[0130] Instance execution status information refers to the status information used to characterize the overall operation of a process instance. It is generated by statistical analysis of the execution status information of multiple sub-processes. Instance execution status information can reflect whether a process instance is running, completed, has encountered an anomaly, or needs to trigger subsequent processing. By maintaining instance execution status information, the embodied intelligent data processing system can uniformly monitor and manage complex data processing processes running across execution environments at the process instance level.

[0131] Maintaining the execution status information of a process instance refers to the continuous updating and management of process instance-level status information during the process instance's execution. This maintenance process can be triggered based on the statistical analysis results of sub-process execution status information from different execution environments, ensuring that the process instance status accurately reflects the current operational status. This maintenance mechanism provides a reliable basis for subsequent sub-process triggering, exception handling, process recovery, or status display.

[0132] In this embodiment, during the execution of a process instance, execution status information corresponding to each sub-process from different execution environments is collected, and the execution status information is subjected to unified statistical analysis to form instance execution status information at the process instance level, which reflects the overall operating status of the process instance in multiple execution environments. Through this method, the embodied intelligent data processing system can centrally aggregate and process the execution statuses scattered across different execution environments, even when sub-processes are running in cloud and edge execution environments respectively, thereby achieving continuous tracking and status maintenance of the overall execution status of the process instance.

[0133] This embodiment statistically analyzes the execution status information of sub-processes from different execution environments and maintains the instance execution status information of process instances based on the statistical analysis results. This enables the embodied intelligent data processing system to uniformly perceive and manage the overall execution status of process instances in scenarios where multiple execution environments are running in parallel, thereby improving the observability and state consistency of process instances in cross-cloud and edge execution environments. Addressing the problem of sub-processes being distributed across different execution environments, resulting in dispersed execution states and difficulty in forming a global state view, this embodiment adopts a process instance state maintenance concept based on cross-execution environment state aggregation and statistical analysis. This achieves unified management of the overall execution status of process instances, reduces anomaly localization and state maintenance costs, and improves the operational stability and maintainability of the embodied intelligent data processing process.

[0134] In some embodiments, the preset triggering conditions may include at least one of the following: at least some sub-processes are executed successfully; at least some sub-processes fail to execute; the data processing results meet preset numerical conditions; and a preset number of data processing results are generated.

[0135] Preset trigger conditions can be used to determine the execution logic of sub-processes within a process instance. They indicate under what circumstances the execution of subsequent sub-processes or corresponding process processing operations are triggered. Preset trigger conditions can be configured during the definition phase of the embodied intelligent data processing process and are dynamically evaluated during the execution of the process instance. By setting preset trigger conditions, event-driven execution of the process instance can be achieved, enabling the embodied intelligent data processing process to flexibly advance based on the execution status of sub-processes or data processing results, without relying on a fixed execution order.

[0136] At least some sub-processes executed successfully. This can mean that among multiple parallel, batch, or collaboratively executed sub-processes, some or all, or one or more, sub-processes completed execution and their execution status was determined to be successful. This preset trigger condition does not require all sub-processes to execute successfully, but allows subsequent processing logic to be triggered in advance if some succeeds. This preset trigger condition is suitable for scenarios that need to quickly advance the process or trigger subsequent sub-processes based on successful samples, such as triggering cloud data processing or model retraining after completing real device evaluation in a partial edge execution environment.

[0137] At least some sub-processes failed, which can mean that during the execution of multiple sub-processes, the execution status of some or all, or one or more sub-processes, was determined to have failed. This preset trigger condition is used to promptly trigger corresponding processing logic when an exception or error occurs, such as exception analysis, rollback, retry, or compensation operations. By using partial failure as a trigger condition, the waiting time for all sub-processes to complete can be reduced, thereby improving the response speed and processing efficiency of the embodied intelligent data processing system to abnormal situations.

[0138] Data processing results refer to the output data or intermediate products generated after the execution of a sub-process, which reflect the processing effect or output of the sub-process. Data processing results can include at least one of model parameters, evaluation metrics, inference output, sampled data, statistical results, and other structured or unstructured data. Data processing results can serve as input data for subsequent sub-processes and as an important basis for determining preset trigger conditions.

[0139] Meeting preset numerical conditions for data processing results can refer to numerically judging the data processing results generated by sub-processes. When the results meet pre-defined thresholds or numerical ranges, corresponding process control operations are triggered. Preset numerical conditions can include being greater than a threshold, less than a threshold, falling within a specified numerical range, or meeting proportional requirements. For example, when the real-device evaluation metrics reach a preset accuracy threshold, the model release or subsequent verification sub-process is triggered. By introducing numerical condition judgments, process-driven operations based on result quality can be achieved.

[0140] The completion of a preset number of data processing results can refer to the triggering of subsequent sub-processes when the cumulative number of data processing results generated reaches a preset number (e.g., a pre-defined threshold) across multiple sub-processes or executions. This preset triggering condition is suitable for scenarios where subsequent processing is only performed after the number of samples or the scale of results reaches a certain level. For example, after collecting a sufficient number of real data samples, a cloud-based data cleaning or model retraining sub-process can be triggered. By controlling the number of data samples, premature or excessive triggering of subsequent processing can be reduced, improving the stability of the process operation.

[0141] During the execution of a process instance, multiple preset trigger conditions can be comprehensively evaluated. Different preset trigger conditions can be used individually or combined according to logical relationships; for example, multiple preset trigger conditions can be met simultaneously, or any one of the preset trigger conditions can be met to trigger the process. By flexibly configuring the combination of preset trigger conditions, the business needs of different embedded intelligent data processing processes can be adapted, achieving diversification and configurability of process advancement strategies.

[0142] In some embodiments, the process definition information may further include execution control configuration information for limiting the execution scope of sub-processes. The execution control configuration information may be used to indicate that only any consecutive sub-process segments or a single sub-process in the process instance are scheduled and executed.

[0143] In some embodiments, the method may further include: when an execution abnormality is detected in the sub-process, determining updated execution control configuration information based on the execution status information corresponding to the sub-process; and performing at least one processing operation on the process instance based on the updated execution control configuration information.

[0144] In some embodiments, the processing operation may include at least one of retry, rollback, and compensation.

[0145] Process definition information is used not only to characterize multiple sub-processes and their dependencies, but also to define the control strategies and execution constraints during process execution. Process definition information can be configured before process instances are generated and serves as the basis for process instance execution, enabling embodied intelligent data processing systems to adjust process execution behavior through configuration without modifying the process logic itself.

[0146] Execution control configuration information can be a type of control configuration within the process definition information. It is used to limit the actual execution scope and execution method of sub-processes within a process instance. Execution control configuration information can exist in the form of configuration parameters, rule sets, or control identifiers, indicating whether the process instance needs to execute all sub-processes or only a portion of them at runtime. By introducing execution control configuration information, fine-grained control over the execution scope of sub-processes can be achieved without redefining or rebuilding the process structure.

[0147] Limiting the execution scope of sub-processes can refer to constraining the set of sub-processes actually involved in scheduling and execution within a process instance through execution control configuration information. This constraint can apply to the overall execution scope of the process instance or to a local set of sub-processes, ensuring that the embodied intelligent data processing system executes only the necessary process segments in a specific scenario. This mechanism is suitable for engineering scenarios such as process debugging, partial verification, anomaly recovery, or emergency handling, helping to reduce unnecessary execution costs.

[0148] An arbitrary contiguous subprocess segment can refer to a group of subprocesses arranged consecutively according to predetermined dependencies within the subprocess execution sequence described by the process definition information. This contiguous subprocess segment can be specified by execution control configuration information, such as determining the execution scope through start and end subprocess identifiers. By supporting execution control of arbitrary contiguous subprocess segments, the embodied intelligent data processing system can independently run or replay local stages of the process while maintaining the consistency of the process logic.

[0149] A single subprocess refers to a specific subprocess within a process instance that is selected for scheduling and execution independently, without requiring the simultaneous execution of other adjacent subprocesses. By controlling the execution of a single subprocess, independent retries, verification, or debugging of the subprocess can be achieved. For example, if model deployment or real-device evaluation fails, only the corresponding subprocess can be re-executed without re-executing other subprocesses before and after it, thereby improving processing efficiency.

[0150] Subprocess execution exceptions refer to situations where the execution status of a subprocess fails to meet expected conditions during or after execution. Execution exceptions can take various forms, including execution failure, execution timeout, resource unavailability, and results that do not meet preset conditions. By detecting execution exceptions, the embodied intelligent data processing system can promptly trigger subsequent exception handling logic, reducing the continued spread of abnormal states within process instances.

[0151] Execution status information can include success or failure indicators, exception types, execution progress, error codes, and resource usage. By collecting and analyzing execution status information, the embodied intelligent data processing system can provide a reliable data foundation for anomaly detection and handling decisions.

[0152] The updated execution control configuration information refers to the execution control configuration dynamically generated or adjusted based on the execution status information of the corresponding sub-process after an execution anomaly is detected. The updated execution control configuration information can be used to change the subsequent execution scope or execution strategy of the process instance, such as narrowing the execution scope, skipping successful sub-processes, or only retrying the abnormal sub-processes. By dynamically updating the execution control configuration information, the process instance can have adaptive adjustment capabilities during operation.

[0153] After an exception occurs during the execution of a subprocess, processing operations can be performed on the process instance based on the updated execution control configuration information. These operations can be used to restore the process's running state, correct the impact of the exception, or ensure the continuity of the process logic. The processing operations are not limited to a single form but can be flexibly selected based on the exception type and execution strategy.

[0154] Retry refers to the process of rescheduling and executing a subprocess or its corresponding execution unit after an execution error is detected. Retry operations are applicable to scenarios where execution failures are caused by temporary errors, resource fluctuations, or network anomalies. By retrying, the probability of successful execution of a subprocess can be increased without changing the process structure.

[0155] Rollback refers to the process of restoring the execution state of a process instance to a stable state before the exception occurred, after an exception has occurred in the execution of a subprocess. Rollback operations can include undoing the effects of executed subprocesses or restoring relevant state data. By rolling back, the continuous impact of exception-prone subprocesses on the overall state of the process instance can be reduced, making it suitable for scenarios with high requirements for execution consistency.

[0156] Compensation refers to a process where, in situations where a complete rollback is difficult or direct retry is unsuitable, compensatory sub-processes or operations are executed to correct or offset the impact of abnormal sub-processes. Compensation operations can include supplementary execution, state correction, or data repair. Through compensation mechanisms, embodied intelligent data processing systems can maintain the controllability and correctness of process instances in complex or irreversible execution scenarios.

[0157] In this embodiment, by introducing execution control configuration information into the process definition information to limit the execution scope of sub-processes, it instructs that only any consecutive sub-process segments or a single sub-process within the process instance be scheduled and executed, thereby achieving fine-grained control over the process execution scope. During the execution of the process instance, when an execution anomaly of a sub-process is detected, the updated execution control configuration information is dynamically determined based on the execution status information corresponding to the sub-process. Based on the updated execution control configuration information, at least one processing operation is performed on the process instance, including retrying the abnormal sub-process, rolling back the executed sub-process, or compensating for the process status. Through this mechanism, the embodied intelligent data processing system can perform targeted processing on specified sub-processes or sub-process segments without restarting the complete process instance, achieving truncation, recovery, and adjustment of process execution.

[0158] This embodiment limits the execution scope of sub-processes by configuring execution control configuration information during the process definition phase. This allows process instances to execute only consecutive sub-process segments or single sub-processes as needed, supporting scenarios such as debugging and verification, partial retries, and emergency rollbacks. When a sub-process execution fails, the execution control configuration information is dynamically updated based on the execution status information, triggering at least one of retry, rollback, or compensation operations. This enables process instances to quickly recover or adjust their execution paths after an anomaly occurs, reducing the impact of the anomaly on sub-processes and the overall process. Addressing the challenges of long workflows, numerous sub-processes, and the need for rapid recovery and control of local processes in abnormal situations, this embodiment employs a concept of truncated execution and anomaly-driven adjustment based on execution control configuration information. This achieves refined control and efficient recovery of process instances in abnormal scenarios, improving the flexibility, stability, and maintainability of process execution.

[0159] In a specific application scenario, this application proposes a unified resource scheduling scheme for edge-cloud environments in the embodied intelligence industry. Based on a cloud-based workflow orchestration framework, edge execution stages such as real-device inference and real-device evaluation are incorporated into the primary execution unit of the workflow, enabling the workflow to be executed across multiple cloud clusters and multiple edge clusters, thereby constructing an automated scheduling link with a closed edge-cloud loop.

[0160] In some embodiments, the unified resource scheduling scheme for edge and cloud may include a unified workflow model, cross-cluster routing scheduling, edge work pool sharding management, and cross-cluster state aggregation and closed-loop triggering mechanisms.

[0161] In some embodiments, a workflow is used to describe the complete configuration structure for executing tasks. A workflow can be started and executed after deployment is complete, either via an event trigger or a scheduler trigger.

[0162] In some embodiments, a workflow can be broken down into multiple subflows. These subflows can run on different execution clusters to enable cross-cluster task collaboration. Each subflow can be configured with its target execution cluster, execution image, and execution script, thereby achieving flexible adaptation to different execution environments.

[0163] In some embodiments, the workflow serves as the core container and orchestration control unit for task orchestration and scheduling, defining the dependencies between multiple sub-workflows and the overall execution logic. The workflow also maintains execution status information throughout the entire task execution process and supports monitoring the execution status, anomaly recovery, and execution path adjustment during task execution.

[0164] As an example, this application proposes a unified workflow model for unified orchestration and management of multi-domain workflows and sub-workflows.

[0165] As an example, embodiments of this application can abstract the entire lifecycle processing flow of an embodied intelligent model into a workflow, and abstract each execution stage in the processing flow into a sub-workflow that can be independently deployed and executed. Unlike related workflow orchestration methods that are only oriented towards cloud clusters, embodiments of this application extend the execution domain of the sub-workflows into a multi-execution domain structure, with the execution domain including at least a cloud execution domain and an edge execution domain. In some embodiments, the present invention also supports the parallel execution of the same execution stage in multiple edge clusters.

[0166] In some embodiments, to achieve the aforementioned multi-domain execution capability, a multi-dimensional execution control configuration capability is introduced into the metadata of the sub-workflow. The metadata may include, but is not limited to, the following configuration fields.

[0167] Firstly, regarding execution domain and target selection configuration, sub-workflows support specifying execution domain types and describing the scope of edge execution targets through target selectors. Target selectors are used to determine the target execution cluster or execution device range based on preset target selection criteria. Target selection criteria may include region information, tenant identifier, site identifier, robot model or robot grouping information, online device quantity threshold, and resource usage threshold, etc.

[0168] Secondly, regarding execution strategy control, embodiments of this application support configuring the execution relationship between sub-workflows via triggers. Execution relationships can include serial execution, parallel execution, and batch execution. In some embodiments, a canary release strategy is also supported during the edge execution phase. The canary release strategy can be configured based on execution ratio, execution batch, or execution parallelism, and supports configuring corresponding rollback conditions.

[0169] Regarding execution link control, embodiments of this application support a workflow-level truncation mechanism. By configuring execution control configuration information, the embodied intelligent data processing system can select any continuous sub-workflow segment or a single sub-workflow node in the execution workflow to meet engineering application needs such as debugging and verification, emergency rollback, and partial retries.

[0170] Through the aforementioned unified workflow model extension capabilities, the workflow can not only describe cloud execution links, such as sub-processes like data processing, model training, model evaluation, and model compilation, but also execution links for multiple edge clusters, such as sub-processes like model deployment, real-device inference, real-device evaluation, and data sampling and backhaul. This application embodiment can also unify cloud and edge execution links into a single workflow state machine for management, thereby achieving unified task orchestration and execution control across execution domains.

[0171] As an example, embodiments of this application may also provide a cross-cluster routing scheduling mechanism to extend from the task distribution mode to the edge-cloud multi-cluster addressing scheduling mode.

[0172] As an example, embodiments of this application can build cross-cluster routing capabilities in the global scheduling layer to dynamically select the execution cluster and work pool for a subflow run instance (SubflowRun) among multiple cloud clusters and multiple edge clusters. Here, a subflow run instance is used to characterize the running entity of a subflow in a specific execution process.

[0173] In some embodiments, the cross-cluster routing scheduling process can make comprehensive decisions based on multi-dimensional resource and policy information. The scheduling decision information may include at least the following information.

[0174] First, in terms of cloud cluster resource assessment, the computing resources in the cloud cluster can be comprehensively considered, including the resource occupancy of graphics processing units, the utilization rate of central processing units, the congestion of task queues, scheduling priorities, and resource quota strategies.

[0175] Secondly, in terms of edge cluster resource assessment, the capacity status of the edge cluster and the operating status of edge devices can be comprehensively considered. Edge assessment information can include the number of online robots, robot type distribution, robot capability distribution, device health status, network connectivity status, and resource usage.

[0176] Secondly, regarding workflow strategy constraints, comprehensive constraint decisions can be made by combining the scheduling strategies defined in the workflow configuration. Scheduling strategies may include priority execution region strategies, canary release ratio strategies, cost and latency trade-off strategies, task priority strategies, and task preemption strategies, etc.

[0177] In some embodiments, the global scheduling layer can construct a cross-cluster scheduling decision model based on the above multi-dimensional information, determine the target execution environment by evaluating and calculating multiple execution clusters and work pools, and route the sub-workflow running instances to the corresponding target execution environment for execution.

[0178] Through the aforementioned cross-cluster routing and scheduling mechanism, the embodiments of this application enable the edge execution phase to no longer be bound to a single edge cluster, but to dynamically allocate tasks and load balance across multiple edge clusters, thereby improving the overall resource utilization of the edge cloud and enhancing the stability of task execution and the scalability of the embodied intelligent data processing system.

[0179] As an example, this application embodiment also provides an edge work pool sharding management mechanism for building a unified resource orchestration unit in multi-edge cluster scenarios.

[0180] As an example, to adapt to organizational structures with multiple edge clusters coexisting, this application embodiment constructs a work pool system oriented towards the edge execution domain, namely the EdgeWorkPool. The EdgeWorkPool is used to perform logical abstraction and unified management of edge resources, so as to realize the fragmented management and resource aggregation management of edge resources.

[0181] In some embodiments, the edge work pool can support the partitioning and organization of edge resources according to multi-dimensional resource attributes. Resource attributes may include, but are not limited to, region information, site information, tenant information, security domain identifier, and robot model or robot grouping information. Through the above partitioning rules, edge execution resources can be divided into multiple logical resource units, thereby forming a multi-edge work pool structure.

[0182] In some embodiments, each edge work pool may correspond to an edge cluster, or to a specific namespace or resource domain within an edge cluster. Through this resource abstraction method, the edge work pool can serve as a unified resource management object in the cross-cluster scheduling process and can be used to undertake edge sub-workflow tasks routed and allocated by the global scheduling layer.

[0183] In some embodiments, each edge worker pool can be associated with an execution-end worker node. The execution-end worker node is used to receive edge sub-workflow tasks and launch the corresponding execution unit in the edge execution environment. The execution unit may include containerized task instances, such as Kubernetes jobs or Kubernetes container instances (Pods).

[0184] In some embodiments, after starting the execution unit, the execution end worker node can establish a resource binding relationship between the execution unit and the edge node or robot group, thereby executing edge computing tasks such as model deployment, model inference, real machine evaluation, and data sampling and backhaul.

[0185] Through the aforementioned edge work pool sharding management mechanism, this embodiment of the application achieves scalable management of edge resources by logically abstracting edge resources into layers and combining this with the multi-instance deployment capability of execution-end work nodes. When the edge cluster scales up, the embodied intelligent data processing system can maintain stable resource management granularity and scheduling efficiency by adding edge work pools or expanding the number of execution work node instances, thereby improving the overall scalability and task scheduling capability of the edge execution environment.

[0186] As an example, embodiments of this application may also provide a cross-cluster state aggregation and closed-loop triggering mechanism to achieve traceable management and recoverable control of the end-cloud collaborative execution link.

[0187] As an example, to achieve unified orchestration between the cloud and the endpoint, this application embodiment can construct a unified task identity management mechanism. A globally unique identifier is generated for each workflow run instance (FlowRun). Simultaneously, when a subflow run instance (SubflowRun) is scheduled to a target cluster, a traceable mapping identifier is generated within the corresponding target cluster to establish the association between the global workflow run instance and the execution instances within each cluster.

[0188] As an example, embodiments of this application can collect execution status information, key performance indicators, and product metadata from cloud execution environments and multiple edge execution environments, and uniformly transmit the information back to form a unified status view. Through the unified status view, the embodied intelligent data processing system can achieve centralized monitoring and unified traceability of task running status in multiple execution environments (edge, cloud, and edge).

[0189] As an example, based on the establishment of unified state management capabilities, this application embodiment can also support an event-driven closed-loop triggering mechanism. In this mechanism, when a backhaul event is generated during the edge execution phase, the embodied intelligent data processing system can automatically trigger the execution of upstream sub-workflows (e.g., data processing, retraining, and re-evaluation) in the cloud based on preset triggering rules. Backhaul events can include, but are not limited to, event types such as real-device evaluation metrics reaching preset thresholds, failed sample backhaul completion, and high-value samples entering the lake.

[0190] Through the aforementioned event-driven closed-loop triggering mechanism, the embodied intelligence data processing system can form an automated execution closed-loop link, namely: a continuous automatic execution process is formed between the cloud product release stage, the gray-scale verification stage of multiple edge clusters, and the stage of triggering cloud retraining or re-evaluation by back-transmission events, thereby realizing the edge-cloud closed-loop iteration of the embodied intelligence model lifecycle.

[0191] As an example, embodiments of this application can also introduce fault recovery control capabilities at the workflow state machine layer. Fault recovery control capabilities may include task retry mechanisms, task compensation mechanisms, task rollback mechanisms, or idempotent replay mechanisms. Through these mechanisms, when an anomaly occurs in the cross-cluster execution link, the embodied intelligent data processing system can automatically restore the task execution state, thereby reducing manual intervention costs and improving system operational stability.

[0192] This application embodiment constructs a unified workflow model, incorporating the entire processing chain of embodied intelligent models into a unified workflow orchestration system. The entire processing chain includes a cloud-based training chain and a multi-edge real-device execution chain. By uniformly configuring the execution domains, execution dependencies, and execution strategies of sub-processes within the workflow, it achieves automated sequential and parallel scheduling of the long chain from data processing, model training, model evaluation to edge deployment verification and online data closed-loop iteration, thereby improving the automation level and execution efficiency of embodied intelligent model lifecycle management.

[0193] Secondly, this application's embodiments introduce a cross-cluster routing and scheduling mechanism, expanding the edge execution phase from the traditional single edge cluster execution mode to a multi-edge cluster addressable execution mode, and supporting dynamic task allocation and load balancing scheduling among multiple edge clusters. Through the above mechanism, the embodied intelligent data processing system can comprehensively utilize multiple edge execution resources during edge-cloud collaborative execution, thereby improving the overall resource utilization of the edge and cloud and enhancing task execution stability.

[0194] Furthermore, this application embodiment constructs a cross-cluster state aggregation and unified traceability mechanism to achieve unified feedback and centralized management of task execution status, key indicator information, and product metadata across cloud execution environments and multiple edge execution environments, thereby forming a unified state view. Through the aforementioned unified state management capabilities, the embodied intelligence data processing system can significantly reduce the difficulty of anomaly localization and failure recovery costs in cross-cluster execution links, and improve the observability and reproducibility of the embodied intelligence model execution process.

[0195] Furthermore, by supporting canary release strategies, batch verification strategies, and strategic rollback mechanisms, the embodied intelligence data processing system can flexibly express the complex scheduling strategy requirements in embodied intelligence real-device execution scenarios. Through the aforementioned scheduling strategy control capabilities, the embodied intelligence data processing system can improve verification efficiency and enhance system operational security during large-scale robot deployment and verification.

[0196] In summary, the embodiments of this application construct a unified resource scheduling and workflow orchestration mechanism between the cloud and the edge to achieve automated management of embodied intelligent models from cloud training to edge execution and then to data closed-loop iteration, thereby improving the overall resource utilization, task execution stability and engineering maintainability of the embodied intelligent data processing system.

[0197] See Figure 2 , Figure 2 A schematic diagram of an embodied intelligent data processing architecture provided in an embodiment of this application is shown.

[0198] like Figure 2As shown, in some embodiments, the embodied intelligent data processing architecture may include a meta cluster, a cloud cluster, and an edge cluster.

[0199] In some embodiments, a meta-cluster is used to perform workflow orchestration and process control functions related to the lifecycle management of embodied intelligence models. The meta-cluster may include multiple functional stages, such as a data processing stage, a model training stage, a simulation verification stage, and a real-device inference stage. In some embodiments, these functional stages may constitute multiple sub-workflows within a workflow and be orchestrated and executed according to preset dependencies.

[0200] In some embodiments, a cloud cluster is used to execute cloud computing tasks. Multiple job instances can be deployed within the cloud cluster. In some embodiments, the data processing phase, model training phase, and simulation verification phase can each trigger the execution of their respective cloud job instances to complete the data preprocessing, model training, and simulation verification tasks.

[0201] In some embodiments, the edge cluster is used to perform edge computing tasks for real robotic devices. The edge cluster may include multiple edge nodes, such as EdgeNode Robot A and EdgeNode Robot B. In some embodiments, each edge node may deploy at least one job instance to perform edge tasks such as model deployment, real-device inference, and data sampling and backhaul.

[0202] In some embodiments, the sub-workflows corresponding to the real-device inference stage can be scheduled to be executed in the job instances inside edge node robot A and edge node robot B, respectively, thereby enabling parallel verification and data acquisition of the model on multiple robot devices.

[0203] Through the aforementioned embodied intelligence data processing architecture, the embodiments of this application realize a collaborative execution mechanism among the meta cluster, cloud cluster, and edge cluster, thereby supporting the complete processing flow of the embodied intelligence model from cloud training to edge execution and then to data closed-loop backhaul.

[0204] The edge-cloud multi-domain unified workflow model extension mechanism proposed in this application extends the execution domain of sub-workflows from a mode that only supports cloud clusters to a multi-execution domain mode, based on the existing workflow and sub-workflow abstract model. This multi-execution domain mode includes at least a cloud execution domain and an edge execution domain. Through this execution domain extension mechanism, edge execution stages such as real-device inference, real-device evaluation, and sampling feedback can serve as first-class execution units within the workflow system. These stages can be uniformly orchestrated and managed within the same workflow as cloud-based data processing, model training, model evaluation, and model compilation stages, thereby achieving edge-cloud collaborative execution of the embodied intelligent model lifecycle processing chain. Secondly, the sub-workflow target selector mechanism for multi-edge clusters proposed in this application introduces a target selector to the sub-workflows in the edge execution domain, describing the selection range and resource constraints of the edge execution target. Target selection conditions may include region information, site information, tenant identifier, security domain identifier, robot model or robot grouping information, online device quantity threshold, device capability label, and device health status threshold, etc. Through the aforementioned target selector mechanism, this application embodiment can support dynamic addressing and scheduling of the same sub-workflow across multiple edge clusters, thereby achieving cross-edge cluster execution capability and no longer relying on a single edge cluster execution mode. Through the above technical concept, this application embodiment realizes unified orchestration and cross-cluster scheduling capabilities for embodied intelligent workflows in an edge-cloud multi-execution domain environment, thereby improving the resource utilization efficiency and task execution flexibility of the embodied intelligent data processing system.

[0205] See Figure 3 , Figure 3 This is a structural block diagram of an embodied intelligent data processing system provided in an embodiment of this application.

[0206] This application also provides an embodied intelligent data processing system, which includes a receiving module, a generating module, an execution module, and a triggering module.

[0207] The receiving module is used to receive process definition information for defining the embodied intelligent data processing process; the process definition information is used to characterize multiple sub-processes and the dependencies between the multiple sub-processes.

[0208] The generation module is used to generate process instances based on the process definition information.

[0209] The execution module is used to determine the execution environment information corresponding to at least one sub-process in the process instance, and to schedule and execute the sub-process according to the execution environment information corresponding to the sub-process, so as to obtain the execution status information and data processing results corresponding to at least some of the sub-processes; the execution environment information is used to indicate that the sub-process is executed in any of at least two types of execution environments.

[0210] The triggering module is used to trigger the execution of at least one subprocess in the process instance that has a dependency relationship with the corresponding subprocess in the process definition information, based on the execution status information and / or the data processing result, when the execution status information and / or the data processing result meet the preset triggering conditions.

[0211] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0212] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0213] The computer program product may be a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the computer program product of the embodiments of this application is not limited thereto, and the computer program product may be any combination of one or more computer-readable media.

[0214] See Figure 4 , Figure 4 This is a structural block diagram of a computer device provided in an embodiment of this application.

[0215] This application also provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above methods.

[0216] The embodiments of this application do not limit the computer device, which may be, for example, a local computer device, a cloud computer device, a distributed computer device, etc.

[0217] The computer device may include: a memory 110, a processor 120, and a communication interface 130. The memory 110, the processor 120, and the communication interface 130 are connected through internal connection paths.

[0218] The memory 110 is used to store computer programs, which in some implementations may include code for implementing the methods of the embodiments of this application.

[0219] The processor 120 executes the computer program stored in the memory 110 to control the communication interface 130 to receive input data and information, and output operation results and other data. In some implementations, when the solutions of the embodiments of this application are implemented by software or firmware, the computer program used to implement the solutions of the embodiments of this application can be stored in the processor 120 and executed by the processor 120.

[0220] The memory 110 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM). It should be noted that the memory 110 described herein is intended to include, but is not limited to, any memory of these and other suitable types. As an example, the memory 110 includes random access memory (RAM), cache memory, and read-only memory (ROM). The memory 110 stores a computer program that can be executed by processor 120, causing processor 120 to implement the steps of any of the methods described above.

[0221] The processor 120 can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor, or the processor 120 can be any conventional processor.

[0222] In implementation, each step of the above method can be completed by the integrated logic circuitry of the hardware in the processor 120 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules in the processor 120. The software modules can be located in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in the memory 110, and the processor 120 reads the information in the memory 110 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0223] In some implementations, in addition to the hardware units described above, computer devices may also include software modules, such as operating systems, basic input / output systems (BIOS), and application software.

[0224] An operating system is used to manage the hardware and / or software resources of a computer device; it is the kernel and foundation of the computer. The operating system handles fundamental tasks such as managing and configuring memory, determining the priority of system resource allocation, controlling input and output devices, operating the network, and managing the file system. To facilitate user operation, most operating systems provide a user interface for interaction with the system.

[0225] The BIOS is used to perform hardware initialization during the power-on boot phase and to provide runtime services for the operating system and applications. In some implementations, the BIOS can also monitor and display processor temperature and execute temperature protection strategies.

[0226] Application software, also known as an application program, can be understood as software written for a specific user application purpose, and is one of the main categories of computer software. For example, application software can be a program used to achieve purposes such as power control and temperature management.

[0227] It is understood that the specific examples in this application are only intended to help those skilled in the art better understand the implementation of this application, and are not intended to limit the scope of protection of this application.

[0228] It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application.

[0229] It is understood that the various implementation methods described in this application can be implemented individually or in combination, and this application does not limit them.

[0230] Unless otherwise stated, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0231] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0232] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the embodiments described above can be referred to the corresponding processes in other embodiments, and will not be repeated here.

[0233] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0234] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the technical solution in this application, depending on actual needs.

[0235] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0236] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, essentially, or the part that contributes to related technologies, or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0237] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for embodied intelligence data processing, characterized in that, The embodied intelligence data processing method includes: Receive process definition information for defining the embodied intelligence data processing flow; the process definition information is used to characterize multiple sub-flows and the dependencies between the multiple sub-flows; Based on the process definition information, a process instance is generated; For at least one sub-process in the process instance, determine the execution environment information corresponding to the sub-process, and schedule and execute the sub-process according to the execution environment information corresponding to the sub-process to obtain execution status information and data processing results corresponding to at least some sub-processes; the execution environment information is used to indicate that the sub-process is executed in any of at least two types of execution environments; If the execution status information and / or the data processing result meet the preset triggering conditions, based on the execution status information and / or the data processing result, the execution of at least one subprocess in the process instance that has a dependency relationship with the corresponding subprocess in the process definition information is triggered.

2. The embodied intelligence data processing method according to claim 1, characterized in that, The at least two types of execution environments include a cloud execution environment and an edge execution environment. The cloud execution environment is used to execute sub-processes related to at least one of model training, model evaluation, and data processing. The edge execution environment is used to execute sub-processes related to at least one of model deployment, real device inference, real device evaluation, and data sampling. And / or, The process definition information processes the embodied intelligent data processing process into a workflow structure; the multiple sub-processes serve as workflow nodes that can be independently scheduled and executed, and the dependency relationships between the multiple sub-processes are defined in the workflow structure; And / or, The dependency relationship is used to indicate at least one of the following: serial execution relationship, parallel execution relationship, and batch execution relationship among the multiple sub-processes; and / or, The execution environment information is used to indicate whether the same sub-process is executed in parallel or in batches in multiple execution environments; And / or, The preset triggering conditions include at least one of the following: at least some sub-processes are executed successfully; at least some sub-processes fail to execute; the data processing result meets the preset numerical conditions. The preset number of data processing results have been generated.

3. The embodied intelligence data processing method according to claim 1, characterized in that, The step of scheduling and executing the sub-process according to the execution environment information corresponding to the sub-process includes: When the execution environment information indicates that the sub-process is executed in an edge execution environment, at least one target execution environment for executing the sub-process is determined from multiple edge execution environments based on preset target selection conditions; In the at least one target execution environment, the sub-processes are scheduled and executed separately, or the sub-processes are scheduled and executed collaboratively.

4. The embodied intelligence data processing method according to claim 3, characterized in that, The target selection criteria are used to indicate at least one of the following: area information, device type, device capability label, device health status, number of online devices, network status, energy consumption constraints, and task priority strategy.

5. The embodied intelligence data processing method according to claim 3, characterized in that, The process of acquiring the edge execution environment includes: dividing edge resources into multiple edge work pools based on preset sharding rules; each edge work pool serves as an edge execution environment; Each edge work pool is used to represent an edge cluster or a specified resource domain within an edge cluster.

6. The embodied intelligence data processing method according to claim 1, characterized in that, The embodied intelligence data processing method also includes: Statistical analysis is performed on the execution status information of sub-processes from different execution environments in order to maintain the instance execution status information of the process instance.

7. The embodied intelligence data processing method according to claim 1, characterized in that, The process definition information also includes execution control configuration information for limiting the execution scope of sub-processes. The execution control configuration information is used to indicate that only any consecutive sub-process segments or a single sub-process in the process instance are scheduled and executed. The embodied intelligence data processing method also includes: If an execution anomaly is detected in the sub-process, the updated execution control configuration information is determined based on the execution status information corresponding to the sub-process. Based on the updated execution control configuration information, at least one processing operation is performed on the process instance; the processing operation includes at least one of retry, rollback, and compensation.

8. An embodied intelligent data processing system, characterized in that, The embodied intelligent data processing system includes: The receiving module is used to receive process definition information for defining the embodied intelligent data processing process; the process definition information is used to characterize multiple sub-processes and the dependencies between the multiple sub-processes; The generation module is used to generate a process instance based on the process definition information; An execution module is configured to determine the execution environment information corresponding to at least one sub-process in the process instance, and schedule and execute the sub-process according to the execution environment information corresponding to the sub-process, so as to obtain execution status information and data processing results corresponding to at least some sub-processes; the execution environment information is used to indicate that the sub-process is executed in any of at least two types of execution environments; The triggering module is used to trigger the execution of at least one subprocess in the process instance that has a dependency relationship with the corresponding subprocess in the process definition information, based on the execution status information and / or the data processing result, when the execution status information and / or the data processing result meet the preset triggering conditions.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the embodied intelligence data processing method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the embodied intelligence data processing method according to any one of claims 1 to 7.

Images