Multimodal data processing task scheduling optimization method and system for intelligent dolls
Through the multimodal data processing task scheduling optimization system, the problems of timing misalignment and unreasonable resource allocation in multimodal data processing in smart dolls are solved, efficient and stable multimodal data processing and task scheduling are achieved, and the real-time and adaptability of the system are improved.
Patent Information
- Application Number
- CN202510747898.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-06
- Publication Date
- 2025-09-26
- Estimated Expiration
- 2045-06-06
AI Technical Summary
Existing smart dolls have problems such as time sequence misalignment, unreasonable resource allocation, low task scheduling efficiency, and poor system stability in multimodal data processing, making it difficult to meet the real-time and reliability requirements of complex interactive scenarios.
The multimodal acquisition module, task decomposition module, resource allocation module, scheduling execution module and dynamic update module work together to achieve real-time collection, refined analysis, dynamic resource allocation and optimized scheduling of multimodal data, ensure the alignment and resource isolation of different tasks in the time dimension, and dynamically adjust the priority queue.
It improves the accuracy and reliability of multimodal data processing, enhances resource utilization, enhances system stability and interactive real-time performance, adapts to changes in different usage scenarios and task types, and optimizes overall processing efficiency.
Smart Images

Figure CN120256146B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of smart dolls, and in particular to a multimodal data processing task scheduling optimization method and system for smart dolls. Background Art
[0002] With the rapid development of artificial intelligence (AI), smart dolls, as intelligent devices integrating multimodal interactions, are becoming increasingly important in fields such as child companionship and education. These dolls must process multimodal data, including speech, vision, and environmental perception, in real time to achieve complex functions such as natural language interaction, visual recognition, and environmental adaptation. However, existing smart dolls face numerous challenges in processing multimodal data, resulting in system performance and user experience failing to meet practical requirements.
[0003] From the perspective of multimodal data acquisition and processing, traditional smart dolls often use a single-modality data processing architecture, which is unable to efficiently integrate multiple data types such as speech signal sequences, visual image sequences, and environmental sensor data streams. The asynchrony of different modal data in the time dimension makes the data fusion process prone to timing misalignment, which in turn affects the accuracy of subsequent task analysis. For example, a mismatch in the time synchronization between voice commands and visual images can prevent the doll from correctly understanding the user's complex commands.
[0004] In terms of task scheduling and resource management, existing systems lack refined task decomposition and dynamic resource allocation mechanisms. Multimodal data processing tasks typically include multiple parallel subtasks, such as speech recognition, image analysis, and sensor data fusion. Traditional fixed-priority task scheduling methods struggle to flexibly adjust to the real-time characteristics of tasks (e.g., timeliness and computational complexity). This can easily lead to processing delays for urgent tasks (e.g., sudden voice commands), impacting the real-time nature of interactions. Furthermore, resource allocation for edge computing nodes is often based on static configurations, lacking real-time awareness of node load status (e.g., memory capacity, processor utilization) and the dynamic resource requirements of tasks (e.g., fluctuations in computational load). This can lead to wasted resources or task blocking due to insufficient resources.
[0005] Furthermore, the existing system's priority queue mechanism lacks dynamic update capabilities, making it unable to optimize scheduling strategies based on historical task execution data (such as average execution time and resource consumption). As the use cases of smart dolls diversify and the types of tasks become more complex, fixed-weight priority queues can easily lead to decreased scheduling efficiency after long-term system operation, making it difficult to adapt to the usage habits of different users and dynamically changing environmental requirements. For example, in educational scenarios, the complexity of interactive instructions for children of different ages varies, and fixed priorities may not prioritize time-sensitive learning guidance tasks.
[0006] In terms of containerized deployment and isolation, traditional process-level task execution lacks an effective isolation mechanism, making resource contention and interference between different tasks a common occurrence. This can lead to system stability degradation or even crashes, especially when multiple tasks are processed in parallel. Furthermore, runtime environment configuration and management are cumbersome, making it difficult to quickly provide customized execution environments for different tasks (e.g., speech recognition requires a specific acoustic model runtime environment, image analysis requires computer vision library support), increasing system deployment and maintenance costs. Summary of the Invention
[0007] The purpose of the present invention is to provide a multimodal data processing task scheduling optimization method and system for intelligent dolls to solve the problems raised in the above background technology.
[0008] To achieve the above objectives, the present invention provides the following technical solution: a multimodal data processing task scheduling optimization system for intelligent dolls, the system comprising:
[0009] A multimodal acquisition module is used to acquire multimodal input data generated during the operation of the smart doll in real time; the multimodal input data includes a speech signal sequence, a visual image sequence, and an environmental sensor data stream;
[0010] A task decomposition module, configured to parse the multimodal input data into K parallel processing tasks according to a preset task type mapping table; the task type mapping table includes a correspondence between data modalities and computing tasks;
[0011] A resource allocation module, configured to allocate an independently running container instance to each processing task based on the real-time load status of the computing node; the container instance includes a preconfigured runtime environment and computing resource quota;
[0012] A scheduling execution module is used to distribute the container instance to the corresponding edge computing node according to a preset priority queue to perform calculations and synchronously receive calculation result data;
[0013] A dynamic update module is used to periodically adjust the execution weight coefficient of the priority queue according to the calculation result data.
[0014] Preferably, the task decomposition module includes:
[0015] A feature extraction unit, configured to perform time-frequency feature analysis on the speech signal sequence to generate a speech feature vector set;
[0016] An image segmentation unit, configured to perform dynamic target detection on the visual image sequence and generate an image region coordinate data set;
[0017] a data fusion unit, configured to align the speech feature vector set, the image region coordinate data set, and the environmental sensor data stream according to timestamps to generate a synchronous fusion data packet;
[0018] The task generating unit is configured to match the corresponding K processing tasks from the task type mapping table according to the data type of the synchronous fusion data packet.
[0019] Preferably, the resource allocation module includes:
[0020] Node detection unit, used to obtain the available memory capacity and processor occupancy of edge computing nodes in real time;
[0021] A resource prediction unit, used to predict the computing resource requirements of each processing task based on historical task execution time data;
[0022] An instance configuration unit, configured to generate container configuration parameters including a memory limit and a core count for each processing task according to the computing resource requirements;
[0023] An instance deployment unit is used to create an isolated container instance on an edge computing node whose load status meets the requirements according to the container configuration parameters.
[0024] Preferably, the scheduling execution module includes:
[0025] A queue generation unit, configured to generate a priority sorting list including urgent task identifiers according to task processing timeliness requirements;
[0026] A distribution control unit, configured to push the container instances to the task execution queue of the target edge computing node in sequence according to the priority sorting list;
[0027] A status monitoring unit, which is used to capture the execution status of container instances in real time and record task completion timestamps;
[0028] The feedback receiving unit is used to receive the calculation result data returned by the edge computing node through the asynchronous message channel.
[0029] Preferably, the dynamic update module includes:
[0030] Weight calculation unit, used to count the historical average execution time and resource consumption of each task type;
[0031] A coefficient adjustment unit, configured to dynamically attenuate and compensate the task weight coefficients in the priority queue according to the historical average execution time;
[0032] The queue reconstruction unit is used to regenerate an optimized priority sorting list based on the updated weight coefficients.
[0033] Preferably, the present invention also includes a multimodal data processing task scheduling optimization method for an intelligent doll, the method comprising:
[0034] Acquire multimodal input data generated during the operation of the smart doll in real time; the multimodal input data includes a speech signal sequence, a visual image sequence, and an environmental sensor data stream;
[0035] Parsing the multimodal input data into K parallel processing tasks according to a preset task type mapping table; the task type mapping table includes a correspondence between data modalities and computing tasks;
[0036] Allocate an independently running container instance to each processing task based on the real-time load status of the computing node; the container instance includes a pre-configured runtime environment and computing resource quota;
[0037] Distribute the container instance to the corresponding edge computing node according to the preset priority queue to perform calculations and synchronously receive the calculation result data;
[0038] The execution weight coefficient of the priority queue is periodically adjusted according to the calculation result data.
[0039] Preferably, parsing the multimodal input data into K parallel processing tasks according to a preset task type mapping table specifically includes:
[0040] Performing time-frequency feature analysis on the speech signal sequence to generate a speech feature vector set;
[0041] Performing dynamic target detection on the visual image sequence to generate an image region coordinate data set;
[0042] Aligning the speech feature vector set, the image region coordinate data set, and the environmental sensor data stream according to timestamps to generate a synchronous fusion data packet;
[0043] K corresponding processing tasks are matched from the task type mapping table according to the data type of the synchronous fusion data packet.
[0044] Preferably, allocating an independently running container instance to each processing task based on the real-time load status of the computing node specifically includes:
[0045] Obtain the available memory capacity and processor occupancy of edge computing nodes in real time;
[0046] Predict the computing resource requirements of each processing task based on historical task execution time data;
[0047] Generate container configuration parameters including memory limit and number of cores for each processing task according to the computing resource requirements;
[0048] An isolated container instance is created on an edge computing node whose load status meets the requirements according to the container configuration parameters.
[0049] Preferably, distributing the container instance to the corresponding edge computing node for execution of calculation according to a preset priority queue specifically includes:
[0050] Generate a priority list including urgent task identifiers based on task processing timeliness requirements;
[0051] Pushing the container instances to the task execution queue of the target edge computing node in sequence according to the priority sorting list;
[0052] Capture the execution status of container instances in real time and record task completion timestamps;
[0053] Receive the calculation result data returned by the edge computing node through the asynchronous message channel.
[0054] Preferably, the periodic adjustment of the execution weight coefficient of the priority queue according to the calculation result data specifically includes:
[0055] Statistics on the historical average execution time and resource consumption of each task type;
[0056] Performing dynamic attenuation compensation on the task weight coefficients in the priority queue according to the historical average execution time;
[0057] Regenerate the optimized priority sorting list based on the updated weight coefficients.
[0058] Compared with the prior art, the present invention has the following beneficial effects:
[0059] At the multimodal data processing level, the multimodal acquisition module acquires voice, visual, and environmental sensor data in real time. The task decomposition module achieves temporal alignment and refined analysis of multimodal data through feature extraction, image segmentation, data fusion, and task generation units. For example, time-frequency feature analysis of voice signals generates feature vector sets, dynamic target detection of visual images generates coordinate data sets, and synchronized fusion data packets are generated by timestamp alignment. This ensures consistency of data from different modalities in the temporal dimension, provides accurate input for subsequent task processing, effectively solves the problem of temporal misalignment in traditional multimodal data fusion, and improves the accuracy and reliability of data processing.
[0060] In terms of task scheduling and resource management, the resource allocation module realizes the dynamic allocation and containerized deployment of computing resources through node detection, resource prediction, instance configuration and instance deployment units. The load status of the edge computing node is obtained in real time, and resource requirements are predicted in combination with historical task execution data. Container configuration parameters including memory limit and number of cores are generated for each task, and isolated container instances are created on appropriate nodes. This dynamic resource allocation mechanism based on real-time load and task requirements avoids the waste or insufficiency caused by static resource allocation and improves resource utilization. At the same time, the isolation of container instances ensures that resources between different tasks do not interfere with each other, enhancing the stability and reliability of the system. For example, when processing voice interaction and visual tracking tasks at the same time, resource competition between processes is avoided.
[0061] The scheduling and execution module implements priority scheduling and real-time monitoring of tasks through queue generation, distribution control, status monitoring, and feedback receiving units. A priority list containing emergency task identifiers is generated based on task timeliness, ensuring that high-priority tasks (such as urgent voice commands) are executed first, improving the real-time nature of interactions. The status monitoring unit captures the execution status of container instances in real time and records completion timestamps. Combined with the feedback receiving unit, which obtains calculation results through asynchronous message channels, this module implements real-time monitoring and data feedback for the entire task execution process, facilitating the timely detection and handling of anomalies during task execution and ensuring stable system operation.
[0062] In terms of dynamic optimization mechanism, the dynamic update module realizes dynamic optimization of priority queues through weight calculation, coefficient adjustment and queue reconstruction units. The historical average execution time and resource consumption of task types are counted, the weight coefficient is dynamically attenuated and compensated according to the execution time, and the optimized priority sorting list is regenerated. This dynamic adjustment mechanism based on historical data enables the system to automatically optimize the scheduling strategy according to the actual operation situation and adapt to changes in different usage scenarios and task types. For example, in an educational scenario, if the average execution time of a certain type of learning task is longer, the system will automatically adjust its weight coefficient to ensure that subsequent similar tasks can allocate resources and priorities more reasonably, thereby improving overall processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0063] Figure 1 This is a working principle diagram of the multimodal data processing task scheduling optimization system for smart dolls according to the present invention;
[0064] Figure 2 This is the working principle diagram of the scheduling execution module;
[0065] Figure 3 Flowchart of the optimization method for scheduling multimodal data processing tasks. DETAILED DESCRIPTION
[0066] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.
[0067] See also Figure 1-Figure 3 The present invention relates to a multimodal data processing task scheduling optimization system for intelligent dolls. The system optimizes the scheduling of multimodal data processing tasks during the operation of intelligent dolls through the collaborative work of a multimodal acquisition module, a task decomposition module, a resource allocation module, a scheduling execution module, and a dynamic update module. The specific implementation steps are as follows:
[0068] During system operation, the multimodal acquisition module first acquires multimodal input data generated by the intelligent doll in real time. This multimodal input data includes speech signal sequences, visual image sequences, and environmental sensor data streams. The acquisition module collects speech signals through a microphone array integrated into the intelligent doll, captures visual image sequences through a high-definition camera, and acquires real-time environmental data streams through environmental sensors such as temperature and acceleration deployed on the doll's body. This data is then synchronously transmitted to the task decomposition module at a preset frequency.
[0069] After receiving multimodal input data, the task decomposition module parses it into K parallel processing tasks according to a preset task type mapping table. This task type mapping table, pre-stored in the system database, contains the mapping between data modalities and computing tasks, such as speech signals corresponding to semantic understanding tasks and visual images corresponding to object recognition tasks.
[0070] The resource allocation module allocates independent container instances to each processing task based on the real-time load status of the computing node. These container instances contain pre-configured runtime environments and computing resource quotas, such as the Python runtime environment and CPU core quotas, ensuring that different tasks run in isolated containers to avoid resource conflicts.
[0071] The scheduling and execution module distributes the container instances to the corresponding edge computing nodes according to a preset priority queue to execute the calculations and simultaneously receive the calculation results. The priority queue is pre-set based on factors such as task timeliness and resource requirements. For example, urgent voice interaction tasks have higher priority than non-real-time environmental data collection tasks.
[0072] The dynamic update module periodically adjusts the execution weight coefficient of the priority queue according to the calculation result data to adapt to the actual execution conditions of different tasks and optimize the scheduling efficiency of subsequent tasks.
[0073] The technical solution of the present invention is further described in detail below with reference to specific embodiments.
[0074] Example 1:
[0075] The system's task decomposition module is further refined into feature extraction unit, image segmentation unit, data fusion unit and task generation unit. Each unit realizes the analysis of multimodal input data and task generation through orderly collaboration. The following is the specific implementation of each unit:
[0076] The feature extraction unit is responsible for analyzing the time-frequency characteristics of the speech signal sequence and generating a set of speech feature vectors. The smart doll's built-in microphone array continuously collects speech signals from the environment at a preset sampling rate (e.g., 16kHz), forming a continuous speech signal sequence. The feature extraction unit first preprocesses the speech signal, including endpoint detection to remove silent segments and pre-emphasis to boost high-frequency signal energy. The preprocessed speech signal is segmented into multiple short-time frames (e.g., 25ms per frame with a 10ms frame shift). Each short-time frame is windowed (e.g., using a Hamming window) to reduce spectral leakage. Subsequently, the speech signal for each short-time frame is converted from the time domain to the frequency domain using a short-time Fourier transform (STFT), resulting in a corresponding spectrum matrix. Based on the spectrum matrix, the Mel-frequency cepstral coefficients (MFCCs) are calculated. The specific steps are as follows: first, the linear frequency axis is converted to the Mel-frequency axis, and the spectrum is filtered using a Mel filter bank to obtain a Mel-frequency spectrum. The Mel-frequency spectrum is then logarithmized and subjected to a discrete cosine transform (DCT). The first 12-40 order coefficients are extracted as MFCC feature parameters. In addition, auxiliary features such as fundamental frequency and short-time energy can be extracted, and finally a set of speech feature vectors containing multi-dimensional feature parameters is generated, where each vector corresponds to the feature representation of a frame of speech signal.
[0077] The image segmentation unit performs dynamic object detection in visual image sequences and generates a dataset of image region coordinates. The smart doll's onboard high-definition camera captures visual images at a fixed frame rate (e.g., 30 fps), forming a continuous visual image sequence. The image segmentation unit processes each frame using a deep learning object detection algorithm (e.g., the YOLOv5 model). The input image is first resized (e.g., to 640×640 pixels) and normalized to meet the model input requirements. The preprocessed image is then fed into the YOLOv5 network. This network extracts high-level semantic features from the image using a backbone feature extraction network (e.g., CSPDarknet). Feature fusion is performed in the neck network (e.g., FPN+PAN), and finally, the head network performs object classification and bounding box regression. For each detected object, the unit outputs its class label (e.g., "person," "toy"), bounding box coordinates (x1, y1, x2, y2, representing the top-left and bottom-right corners, respectively), and a confidence score. The image segmentation unit screens all detected targets in each frame, retaining those with confidence scores above a preset threshold (e.g., 0.5). This generates a dataset of image region coordinates containing target categories, coordinates, and confidence scores. To meet the real-time processing requirements of the smart doll, the image segmentation unit employs model lightweighting techniques (e.g., channel pruning and quantization) to reduce computational complexity and ensure efficient operation on edge computing nodes.
[0078] The data fusion unit aligns the speech feature vector set, image region coordinate dataset, and environmental sensor data streams based on timestamps and generates a synchronized fusion data packet. The environmental sensor data stream includes data collected by sensors such as temperature, acceleration, and gyroscope. Each sensor outputs data at its own sampling frequency (e.g., 1 Hz for a temperature sensor, 100 Hz for an acceleration sensor), and each data item carries an acquisition timestamp. The speech feature vector set and image region coordinate dataset also record corresponding timestamps (e.g., speech frame start time, image frame acquisition time) when they are generated. The data fusion unit first establishes a time-aligned buffer to store data from the three modalities. For speech feature vectors, the corresponding speech frame start time is used as the timestamp; for image region coordinate data, the image frame acquisition time is used as the timestamp; and for environmental sensor data, the actual acquisition time is used as the timestamp. The data fusion unit then traverses the data from each modality in chronological order, interpolating or sampling the data from the other modalities based on the modality with the smallest timestamp, so that the three modal data items have corresponding data items at the same time point. For example, if a speech feature vector and environmental sensor data are available at a given moment, but image region coordinates are missing, linear interpolation is used to estimate the target coordinates at that moment based on the image data from the preceding and following moments. The aligned three modal data is packaged into a synchronized fusion data packet containing a timestamp, speech feature vector, image region coordinates (if available), and environmental sensor data, providing a unified input format for subsequent task generation.
[0079] The core function of the task generation unit is to match the K corresponding processing tasks from the task type mapping table based on the data type of the synchronized fusion data packet. The task type mapping table is a predefined modality-task mapping relationship table stored in the system's non-volatile memory and can be configured and updated through the management interface. Each record in the mapping table contains a data modality combination and the corresponding processing task type. For example:
[0080] Single speech modality → speech recognition task;
[0081] Single visual modality → image classification task;
[0082] Speech + visual modality → audio-visual interaction task;
[0083] Speech + environmental sensor modality → environmental perception speech feedback task;
[0084] Vision + environmental sensor modality → visual navigation task;
[0085] Speech + vision + environmental sensor modalities → multimodal scene understanding task.
[0086] The task generation unit analyzes the modal composition of a synchronized fusion data packet. For example, if a data packet contains speech feature vectors, image region coordinates, and ambient temperature data, its modal combination is speech + vision + environmental sensor. It then searches the task type mapping table for a matching modal combination. If a perfect match exists, a corresponding processing task (such as a multimodal scene understanding task) is generated. If no perfect match exists, a fuzzy match is performed based on the similarity of the modal combinations, for example, prioritizing records containing more identical modalities. For each matched processing task, the task generation unit generates a separate task descriptor containing information such as the task type, input data pointers, and a priority identifier. These multiple task descriptors constitute K parallel processing tasks, which are transmitted via a task queue to the resource allocation module for further processing. To ensure accurate task generation, the task type mapping table can set a default task type. If no match is found, a default general data processing task is generated to prevent data loss.
[0087] In the overall operational flow of the task decomposition module, each unit collaborates through a data buffer and event-driven mechanism. The feature extraction unit and image segmentation unit process speech and visual data, respectively, generating feature vectors and coordinate data that are stored in real time in a shared data buffer. The data fusion unit periodically reads data from the buffer, performs time alignment and fusion operations, and stores the resulting synchronized fused data packets in the task generation queue. The task generation unit monitors the task generation queue and, upon detecting a new data packet, immediately triggers the task matching and generation process. The entire process utilizes a pipeline architecture to ensure efficient real-time processing of multimodal data and task generation, providing an accurate and ordered set of input tasks for subsequent resource allocation and task scheduling. Through multi-dimensional feature analysis in the feature extraction unit, efficient object detection in the image segmentation unit, precise time alignment in the data fusion unit, and flexible task matching in the task generation unit, the task decomposition module automatically converts raw multimodal data into executable processing tasks, laying a solid foundation for optimizing the scheduling of multimodal data processing tasks for the smart doll.
[0088] Example 2:
[0089] The implementation of the resource allocation module involves the coordinated work of the node detection unit, resource prediction unit, instance configuration unit, and instance deployment unit, achieving dynamic and reasonable allocation of computing resources through layered processing. The following is the specific implementation of each unit:
[0090] The node detection unit is responsible for monitoring the operating system interfaces of edge computing nodes in real time, obtaining real-time load status information such as available memory and processor utilization. This unit triggers the monitoring process through a scheduled task (e.g., executed every 500ms). It first establishes a communication connection with the edge computing node. For Linux nodes, it accesses the node's operating system through the SSH protocol or the REST API. To obtain available memory, the node detection unit reads the / proc / meminfo file, parses the MemFree and Buffers / Cached fields, and calculates the current total available memory. For example, MemFree represents unused physical memory, Buffers represents block device cache, and Cached represents file system cache. The three fields are summed to obtain the actual available memory. To obtain processor utilization, the unit uses CPU time statistics from the / proc / stat file. The ratio of CPU idle time between two sampling times to the total CPU time is calculated to determine CPU utilization. Specifically, the CPU line data in the / proc / stat file, including time fields such as user, nice, system, and idle, is read. The ratio of the idle time change between two samples to the total time change is calculated, which is the CPU idle rate. The CPU utilization rate is obtained by subtracting the idle rate from 1. The node detection unit also obtains other system information, such as disk I / O status and network bandwidth utilization. This information is used as auxiliary indicators to evaluate the overall load of the node. All monitoring data is encapsulated into a node status report, which contains fields such as node ID, timestamp, memory capacity, and CPU utilization, and is sent to the resource prediction unit via a message queue.
[0091] The resource prediction unit uses a time series analysis algorithm based on historical task execution time data to predict the computing resource requirements for each processing task. The unit maintains a historical task execution database, recording information such as the type, input data size, start time, end time, CPU usage duration, and peak memory usage of each completed task. For each newly received processing task, the resource prediction unit first filters the database for historical execution records of similar tasks based on task type. For example, for a speech recognition task, the unit filters all historical speech recognition task execution data. It then uses a time series analysis algorithm (such as the ARIMA model) to model and predict the historical execution time data. The specific steps are as follows: First, a stationarity test (such as an ADF test) is performed on the historical execution time series. If the series is non-stationary, it is differentiated to make it stationary. The order (p, d, q) of the ARIMA model is then determined based on the autocorrelation function (ACF) and partial autocorrelation function (PACF) of the stationary series. The model parameters are then estimated using maximum likelihood estimation. Finally, the trained model is used to predict the execution time of the current task. In addition to predicting execution time, the resource prediction unit also analyzes the resource consumption patterns of historical tasks. For example, speech recognition tasks typically require high CPU computing power, while image recognition tasks require large amounts of memory and GPU resources. The unit predicts the CPU core and memory requirements for the current task based on the task's input data size (such as speech duration and image resolution). For example, longer speech segments are predicted to require more CPU computing time and memory space to complete recognition. The prediction results are output as resource requirement descriptors, which contain information such as the predicted execution time, CPU core count requirements, and memory space requirements, and are then transmitted to the instance configuration unit.
[0092] The instance configuration unit generates container configuration parameters for each processing task, including memory limits and core counts, based on computing resource requirements. This unit receives the resource requirement descriptor output by the resource prediction unit and, combined with the actual resource availability of the edge computing node, generates the optimal container configuration. First, the instance configuration unit checks the total available resources of the edge computing node to ensure that the allocated resources do not exceed the node's capacity. For example, if a node has 8GB of available memory but the task is predicted to require 10GB, the configuration needs to be adjusted or a different node needs to be selected. Then, based on the task's priority and resource requirements, the container's memory limit and CPU core count are determined. High-priority tasks are prioritized, while low-priority tasks are appropriately reduced in resource constraints. For example, for urgent voice interaction tasks, 100% of the predicted memory requirements and 120% of the predicted CPU core count are allocated as a safety margin. For less urgent environmental data processing tasks, 80% of the predicted memory requirements and 90% of the predicted CPU core count are allocated. The instance configuration unit also considers the task's resource elasticity requirements, setting resource limits and resource request parameters for the container. The resource limit parameter defines the maximum amount of resources a container can use, preventing the container from overusing resources and affecting other tasks. The resource request parameter defines the amount of resources requested when the container starts, serving as a reference for the scheduler to allocate resources. For example, a task is configured with a memory limit of 2GB and a memory request of 1.5GB, a CPU limit of 2 cores, and a CPU request of 1 core. In addition, the instance configuration unit also generates other container configuration parameters, such as the container image address, environment variables, and mount points. These parameters together constitute a complete container configuration file, usually in JSON or YAML format, which is used to guide the creation and operation of the container.
[0093] Based on the container configuration parameters, the instance deployment unit creates isolated container instances on edge computing nodes whose load status meets the requirements. This unit receives the container configuration file generated by the instance configuration unit and, combined with the node status report provided by the node detection unit, selects the most suitable edge computing node for container deployment. First, the instance deployment unit screens all available nodes, excluding those with excessive load or unavailable capacity. For example, it excludes nodes with CPU utilization exceeding 80% or available memory below the task's memory request. Then, among the remaining candidate nodes, it selects the optimal node based on its load balancing policy. The load balancing policy can be based on various factors, such as the node's current load, historical performance, and network latency. For example, it might select the node with the lowest CPU utilization or the node with the lowest communication latency with the smart doll. Once the target node is selected, the instance deployment unit establishes a connection to the target node using a container engine API (such as the Docker API) and sends a container creation request. This request contains the contents of the container configuration file, instructing the container engine to create a container instance with the specified resource limits and configuration parameters. Upon receiving the request, the container engine first pulls the required container image (if it doesn't exist locally), then creates the container according to the configuration parameters and starts the application. The instance deployment unit monitors the container creation process to ensure that the container starts successfully and runs normally. For containers that fail to create, the instance deployment unit records the error information and attempts to redeploy them on other candidate nodes. After the container is successfully created, the instance deployment unit reports the container's operating status (such as container ID, operating status, and resource usage) to the scheduling execution module and updates the node status report to reflect the node's latest load.
[0094] In the overall operational flow of the resource allocation module, data flow and collaboration between various units are achieved through message queues and a state database. The node detection unit periodically writes node status reports to a shared state database for query by other units. The resource prediction unit retrieves historical task data and current node status from the database, executes a prediction algorithm, and sends the results to the instance configuration unit. The instance configuration unit generates container configuration parameters based on the prediction results and passes them to the instance deployment unit via a message queue. The instance deployment unit deploys the container according to the configuration parameters and feeds the deployment results back to the scheduling execution module and updates the state database. The entire process utilizes an asynchronous processing model, ensuring that each unit can operate independently and efficiently. Through the layered processing of the resource allocation module, the system can dynamically and rationally allocate computing resources based on actual task requirements and the real-time status of nodes, achieving optimal resource utilization of edge computing nodes and efficient execution of multimodal data processing tasks. The design of the resource allocation module fully considers the specific application scenarios of smart dolls, such as limited edge computing resources, high real-time requirements for tasks, and concurrent execution of multiple tasks. Through refined resource management and scheduling, it provides a stable and efficient computing support environment for smart dolls.
[0095] Example 3:
[0096] The implementation of the scheduling execution module covers the coordinated operation of the queue generation unit, distribution control unit, status monitoring unit and feedback receiving unit, and realizes the orderly distribution of tasks, real-time monitoring and result reception through process design. The following is the specific implementation of each unit:
[0097] The core function of the queue generation unit is to generate a priority sorted list containing urgent task identifiers based on the timeliness requirements of task processing. The system pre-defines a timeliness label for each task type in the task type mapping table. For example, voice interaction tasks are marked as "real-time tasks" and the response time is required to be less than 200ms; environmental data storage tasks are marked as "non-real-time tasks" and the response time is allowed to be within 5s. When the task generation unit outputs K parallel processing tasks, each task descriptor already contains the corresponding task type information. The queue generation unit parses the task descriptor, obtains the timeliness label of the task from the task type mapping table, and assigns a priority level to the task according to the preset priority rules. The priority rules can be set as follows: real-time tasks have a higher priority than quasi-real-time tasks, and quasi-real-time tasks have a higher priority than non-real-time tasks; within the same timeliness level, the priority is adjusted according to the amount of task data, and tasks with smaller data volumes are processed first.
[0098] In the specific implementation, the queue generation unit maintains a priority rule configuration table, for example:
[0099] Real-time tasks (such as speech recognition and emergency control commands) → Priority 1 (highest);
[0100] Quasi-real-time tasks (such as image target tracking and environmental parameter warning) → Priority level 2;
[0101] Non-real-time tasks (such as historical data statistics and firmware upgrades) → Priority level 3 (lowest).
[0102] For each task, the queue generation unit first determines whether it is an urgent task. Urgent tasks are typically triggered by a timeliness tag or a specific task type (such as a fault alarm task). For example, a task type of "collision detection alarm" is automatically marked as an urgent task, assigned the highest priority, and inserted at the top of the priority list. Non-urgent tasks are sorted based on priority level and data volume. Data volume is measured by the number of bytes or feature dimensions of the task input data, such as the number of dimensions of a speech feature vector set or the number of targets in an image region coordinate dataset. The queue generation unit uses a quick sort algorithm (such as heap sort) to sort tasks, generating a priority list containing fields such as task ID, priority level, urgent task indicator (yes / no), and data volume. This list is stored in a linked list structure, allowing the subsequent distribution control unit to quickly access and delete processed tasks.
[0103] The distribution control unit is responsible for pushing container instances to the task execution queue of the target edge computing node in sequence according to the priority list. This unit interacts with the queue generation unit through shared memory or message queues to obtain the latest priority list in real time. The distribution control process is as follows: First, the distribution control unit extracts the container instance information corresponding to the highest-priority task from the priority list, including container configuration parameters and the list of target edge computing nodes (pre-specified by the resource allocation module). Then, a communication connection is established with the target node through message middleware (such as RabbitMQ). Message middleware supports a publish-subscribe model to ensure reliable and asynchronous task distribution.
[0104] When pushing a container instance, the distribution control unit serializes the container configuration parameters into binary data (e.g., using Protocol Buffers format) and transmits it over the network to the target node's task execution queue. The task execution queue is a first-in-first-out (FIFO) queue maintained locally on the edge computing node, used to temporarily store container instances to be executed. To avoid network congestion, the distribution control unit sets a sending rate limit, for example, pushing a maximum of five container instances per second to a single node. For urgent tasks, the distribution control unit adopts a preemptive strategy, interrupting the currently pushed non-urgent tasks and giving priority to sending container instances for urgent tasks to ensure the timeliness of urgent tasks.
[0105] In addition, the distribution control unit maintains a task distribution log, recording information such as the push time, target node, and task priority for each container instance, to facilitate subsequent troubleshooting and performance analysis. If a network interruption or node unreachability occurs during the push process, the distribution control unit re-adds the task to the priority sorting list and marks it as "undelivered" pending the next round of distribution attempts. If the number of retries exceeds a preset threshold (e.g., three), an error report is generated and sent to the system management module, triggering manual intervention.
[0106] The primary responsibility of the status monitoring unit is to capture the execution status of container instances in real time and record task completion timestamps. This unit interacts with edge computing nodes through the status monitoring interface provided by the container engine (such as Docker's events API or the crictl command), capturing container instance lifecycle events in the form of streaming data, including state changes such as "created," "started," "running," "paused," "exited," and "failed." For each container instance, the status monitoring unit maintains a status tracking table, recording information such as the container ID, task ID, current state, state change time, and accumulated runtime.
[0107] During task execution, the status monitoring unit periodically (e.g., every 100ms) polls the container status of the edge computing node to ensure timely capture of state changes. Upon detecting a container status change to "Exited" or "Failed," the status monitoring unit immediately records the task completion or failure timestamp and analyzes the cause of the failure (e.g., insufficient memory, excessive CPU utilization, application crash, etc.). For failed tasks, the status monitoring unit marks the task as "Execution Failed," writes the failure reason to the task log, and notifies the distribution control unit to reschedule the task (if a retry policy is configured).
[0108] To reduce monitoring overhead, the state monitoring unit uses an event-driven mechanism, triggering data updates only when container status changes, rather than continuously polling all containers. Furthermore, the state monitoring unit supports parallel monitoring of multiple edge computing nodes, enabling state capture in highly concurrent scenarios through multithreading or asynchronous I / O techniques. Monitoring data is transmitted in real time to the system's core modules via message queues for use by the scheduling execution module and the dynamic update module. For example, the dynamic update module can adjust the weight coefficient of the priority queue based on the task execution status.
[0109] The feedback receiving unit receives computation results from edge computing nodes via an asynchronous message channel. This asynchronous message channel uses a non-blocking communication model, implemented using HTTP persistent connections or the WebSocket protocol, to ensure timely access to computation results without blocking the system's main thread. After completing the computation for the container instance, the edge computing node serializes the computation result data (e.g., in JSON format) and sends it to the feedback receiving unit via the message channel.
[0110] The format of the calculation result data depends on the task type, for example:
[0111] Speech recognition task → returns a text string (such as "Hello, I am a smart doll");
[0112] Image object tracking task → returns a sequence of target coordinates (e.g., [[x1,y1,t1],[x2,y2,t2],…]);
[0113] Environmental data processing task → Returns statistical values (such as "temperature: 25°C, humidity: 60%").
[0114] After receiving data, the feedback receiving unit first performs an integrity check, verifying fields such as data length and checksum to ensure that the data has not been lost or corrupted during transmission. Once the integrity check passes, the result data is routed to the smart doll's business logic module based on the task ID. For example, speech recognition results are sent to the dialogue management module, and image tracking results are sent to the motion control module. For data that fails the integrity check, the feedback receiving unit logs the error and requests the edge computing node to resend the result (if a retransmission mechanism is configured).
[0115] To handle the high concurrency of returned calculation results, the feedback receiving unit utilizes thread pooling technology, assigning an independent processing thread to each message channel connection to avoid blocking issues caused by single-threaded processing. Furthermore, the system implements a result cache queue to cache temporarily unprocessed calculation results, preventing data backlogs from causing system crashes. The cache queue is designed with a finite length. When the queue is full, old data is discarded according to the first-in, first-out principle, and a discard log is recorded for system optimization.
[0116] The four units of the scheduling execution module work closely together through data links and control logic to form a complete task scheduling execution process:
[0117] ① The queue generation unit generates a priority list based on task timeliness and data volume, triggering the task push process of the distribution control unit;
[0118] ② The distribution control unit pushes the container instances to the edge computing nodes in order of priority, and updates the task tracking information of the status monitoring unit at the same time;
[0119] ③ The status monitoring unit captures the container status in real time and triggers the data receiving process of the feedback receiving unit when the task is completed;
[0120] ④ The feedback receiving unit obtains the calculation results and routes them to the business module, and at the same time feeds back the task completion information to the dynamic update module for adjusting the priority queue weight.
[0121] In practical application scenarios of smart dolls, for example, when a user interacts with the doll through voice, the queue generation unit marks the voice recognition task as urgent, and the distribution control unit prioritizes pushing its container instance to edge nodes with stronger computing capabilities. The status monitoring unit tracks the task execution status in real time. Upon detecting successful task completion, the feedback receiving unit immediately obtains the recognition result and transmits it to the dialogue module, driving the doll to respond in real time. Simultaneously, the status monitoring unit records the task completion timestamp and resource consumption data, providing an optimization basis for the dynamic update module. This entire process, through modular design and asynchronous communication mechanisms, ensures the efficient and reliable execution of multimodal data processing tasks in an edge computing environment, meeting the strict real-time and stability requirements of the smart doll.
[0122] Example 4:
[0123] The implementation of the dynamic update module consists of a weight calculation unit, a coefficient adjustment unit, and a queue reconstruction unit. Through periodic data statistics, coefficient adjustment, and queue optimization, it achieves adaptive updates of the priority queue. The following is a detailed implementation of each unit:
[0124] The core function of the weight calculation unit is to calculate the historical average execution time and resource consumption of each task type. This unit maintains a historical task database that stores detailed information about all completed tasks over a period of time (e.g., the last 24 hours). Each record includes fields such as task type, execution start time, execution end time, CPU core usage duration, peak memory usage, and data input size. The database uses a time series database (such as InfluxDB) to support efficient time series data query and statistical analysis.
[0125] The specific process of weight calculation is as follows: First, the weight calculation unit groups historical task records according to task type, for example, all speech recognition tasks are divided into one group, and image recognition tasks are divided into another group. For each task group, the following statistical operations are performed:
[0126] Extract the time difference between the execution end time and the execution start time of all tasks in the group and calculate the arithmetic mean to obtain the historical average execution time of the task type. For example, if a task group contains 1000 speech recognition task records with a total execution time of 500,000ms, the average execution time is 500ms.
[0127] CPU core usage duration: Add the CPU core usage duration of each task (for example, multiply the number of CPU cores recorded for each task by the execution time), then divide by the number of tasks to obtain the average CPU core usage duration for that task type. For example, if the total CPU core usage duration of 1,000 tasks is 300,000ms / core, the average CPU core usage duration is 300ms / core.
[0128] Peak Memory Usage: Extract the peak memory usage of all tasks in the group and calculate the median or average to use as the average peak memory usage for the task type. Using the median reduces the impact of outliers on the statistical results. For example, if the peak memory usage data is [1.2GB, 1.5GB, 1.8GB, 2.0GB, 10GB], the median is 1.8GB, which better reflects normal memory usage.
[0129] The weight calculation unit triggers the statistical process periodically (e.g., every 10 minutes) to ensure the timeliness of historical data. The statistical results are stored in an in-memory hash table, keyed by task type. These tables contain fields such as average execution time, average CPU core usage time, and average peak memory usage, for quick query by the coefficient adjustment unit.
[0130] The coefficient adjustment unit dynamically attenuates the task weight coefficients in the priority queue based on the historical average execution time output by the weight calculation unit. The system pre-defines a set of weight coefficient adjustment rules. These rules are based on the comparison of the average execution time of the task type with the preset benchmark value to achieve quantitative adjustment of the weight coefficient. The specific design of the adjustment rules is as follows:
[0131] a. Baseline value setting: A baseline value (T_base) for ideal execution time is set for each task type. This value is determined based on the timeliness requirements of the task and the average processing power of the edge computing node. For example, the baseline value for speech recognition tasks is set to 400ms, and the baseline value for image recognition tasks is set to 800ms.
[0132] b. Deviation calculation: For each task type, calculate the deviation rate (ΔT) between its historical average execution time (T_avg) and the baseline value. The formula is: ΔT = (T_avg - T_base) / T_base × 100%. If ΔT is positive, it means that the actual execution time exceeds the baseline value; if ΔT is negative, it means that the actual execution time is better than the baseline value.
[0133] c. Decay Compensation Strategy: When ΔT > 0 (execution duration is too long): The weight coefficient is decayed based on the deviation rate, with the decay rate proportional to the deviation rate. For example, for every 10% increase above the baseline value, the weight coefficient decays by 5%. Assuming a ΔT of 20% for a certain task type, the weight coefficient decays from its initial value of 1.0 to 1.0 × (1 - 20% / 10% × 5%) = 0.9.
[0134] When ΔT < 0 (execution time is too short): The weight coefficient is compensated and increased based on the deviation rate, with the increase proportional to the absolute value of the deviation rate. For example, for every 10% drop below the baseline value, the weight coefficient increases by 3%. If the ΔT of a task type is -15%, the weight coefficient increases to 1.0 × (1 + 15% / 10% × 3%) = 1.045.
[0135] d. Boundary Limit: To prevent excessive fluctuations in the weight coefficient, a range of values is set for the weight coefficient (e.g., 0.5 ≤ weight coefficient ≤ 2.0). If the calculated coefficient exceeds this range, the boundary value is used as the final adjustment result.
[0136] When performing adjustments, the coefficient adjustment unit traverses all task types in the priority queue and updates the weight coefficients based on their corresponding deviation rates and adjustment rules. The adjusted weight coefficients are stored in real time in the system's shared configuration center and are accessible to the queue reconstruction unit and queue generation unit.
[0137] The queue reconstruction unit regenerates an optimized priority list based on the updated weight coefficients. The core logic of priority sorting is to combine the weight coefficient of the task type with the real-time attributes of the task (such as data volume and urgency) to form a comprehensive priority score. The specific implementation steps are as follows:
[0138] ① Comprehensive score calculation: For each task type, the comprehensive priority score formula is defined as: Score = weight coefficient × priority level coefficient × urgency coefficient × data volume adjustment factor
[0139] Priority level coefficient: Assign a value based on the timeliness level of the task type (for example, the real-time task level coefficient is 3, quasi-real-time is 2, and non-real-time is 1).
[0140] Urgency coefficient: Urgent tasks are assigned a value of 1.5 and non-urgent tasks are assigned a value of 1.0.
[0141] Data volume adjustment factor: This factor is adjusted based on the amount of task input data. For every 10% increase in data volume, the factor is multiplied by 0.95 (this means that the priority of tasks with large data volumes is slightly reduced to avoid blocking small tasks).
[0142] ② Task Sorting: The queue reconstruction unit sorts all pending tasks from highest to lowest based on their comprehensive scores. A stable sorting algorithm (such as merge sort) is used to ensure that tasks with the same score maintain their original order, preventing scheduling stability from being affected by sorting jitter.
[0143] ③ Urgent Task Insertion: In the sorted list, check whether there are any newly arrived urgent tasks. If so, insert the urgent task directly to the top of the list and adjust the order of other tasks to ensure that the urgent task is executed first.
[0144] ④ Queue persistence: The reconstructed priority list is stored in an in-memory ring buffer, supporting fast insertion, deletion, and query operations. Furthermore, key list information (such as task ID and priority score) is regularly synchronized to the disk database to prevent queue information loss due to system power outages.
[0145] The three units of the dynamic update module implement closed-loop optimization through data transmission and rule-driven operation. The specific process is as follows:
[0146] ① Data collection and statistics: The weight calculation unit regularly extracts data from the historical task database, calculates the average execution time and resource consumption of each task type, and updates it to the memory hash table.
[0147] ② Coefficient adjustment and rule application: The coefficient adjustment unit applies preset rules to adjust the weight coefficient of the task type based on the deviation between the average execution time and the benchmark value to ensure that the weight coefficient reflects the actual execution efficiency of the task.
[0148] ③ Queue reconstruction and priority update: The queue reconstruction unit recalculates the comprehensive priority score of the task based on the new weight coefficient and real-time attributes of the task, and generates an optimized priority sorting list for use by the distribution control unit of the scheduling execution module.
[0149] ④ Feedback and iteration: The adjusted priority queue generates new execution data during the task scheduling process. These data are collected again by the weight calculation unit, forming a closed-loop iterative process of "statistics-adjustment-reconstruction-feedback", so that the priority queue can continuously adapt to changes in system load and task characteristics.
[0150] In the actual operation scenario of the smart doll, for example, when the doll enters a dimly lit environment, the average execution time of the visual image recognition task may be prolonged due to increased image noise. The weight calculation unit detects that the average execution time of this task type exceeds the baseline value, and the coefficient adjustment unit attenuates its weight coefficient according to the deviation rate. After the queue reconstruction unit reorders, the priority of the visual task decreases, and the system will prioritize the voice interaction tasks with shorter execution times to ensure the doll's real-time response to user commands. As the ambient light improves, the execution time of the visual task shortens, the weight coefficient gradually recovers, and the priority returns to normal. Through continuous optimization of the dynamic update module, the system can automatically adjust the scheduling strategy in the case of multimodal task load fluctuations, balance task timeliness and resource utilization, and improve the stability and responsiveness of the smart doll's overall data processing system.
[0151] Data consistency: Atomic operations and locking mechanisms are used between the weight calculation unit and the coefficient adjustment unit to ensure the consistency of statistical data during the adjustment process, avoiding data errors caused by concurrent access.
[0152] Adjustment frequency control: The period of the dynamic update module is set to be greater than 10 times the average task execution time (such as 10 minutes) to avoid queue instability caused by too frequent adjustments.
[0153] Fault-tolerance mechanism: If the weight calculation unit cannot obtain historical data (such as a database failure), the default weight coefficient (initial value is 1.0) is used to reconstruct the queue to ensure that the system does not crash due to data loss.
[0154] Example 5:
[0155] The implementation of the dynamic load balancing module consists of a resource monitoring unit, a load prediction unit, a migration decision unit, and an execution control unit. Through real-time resource monitoring, load trend prediction, intelligent migration decision-making, and precise execution control, it achieves dynamic load balancing between edge computing nodes. The following is the specific implementation of each unit:
[0156] The resource monitoring unit obtains real-time CPU, memory, and network bandwidth usage for each edge computing node through the container orchestration platform's monitoring API. This unit uses a periodic polling mechanism (e.g., every 30 seconds) to establish a connection with the API server of container orchestration platforms such as Kubernetes and Docker Swarm, sending resource query requests. For each edge computing node, the unit collects the following key metrics: CPU utilization (calculated by summing the CPU time of all containers on the node), memory utilization (percentage of physical memory used), and network bandwidth utilization (inbound and outbound traffic rates). The resource monitoring unit also collects granular container-level metrics, such as individual container CPU limits, memory requests, and network IOPS. To reduce data transmission volume, monitoring data is updated incrementally, transmitting only metrics whose changes exceed a threshold (e.g., 5%). All monitoring data is stored in a time series database (e.g., Prometheus), retaining the last seven days of historical data for trend analysis and anomaly detection.
[0157] The load forecasting unit uses a time series analysis algorithm based on historical monitoring data to predict the load trend of each edge computing node within the next 30 minutes. This unit extracts historical resource usage data for each node from a time series database and performs data preprocessing, including filling missing values (using linear interpolation) and smoothing outliers (using a moving average filter). The unit then applies the Autoregressive Integrated Moving Average (ARIMA) model to the preprocessed data. The specific steps are: first, a stationarity test (ADF test) is performed. If the series is non-stationary, differencing is performed. The model order (p, d, q) is then determined based on the autocorrelation function (ACF) and partial autocorrelation function (PACF). Finally, the model parameters are fitted using maximum likelihood estimation. For the forecast results, a 95% confidence interval is calculated to assess the uncertainty of the forecast. In addition to the ARIMA model, the load forecasting unit also supports deep learning models such as LSTM (Long Short-Term Memory Network), which can achieve more accurate forecasts for load patterns with significant cyclicality (such as high loads during the day and low loads at night). The forecast results include the CPU usage forecast, memory usage forecast, and network bandwidth utilization forecast at 5-minute intervals over the next 30 minutes.
[0158] Based on load forecasts and a cost-benefit analysis model, the migration decision unit decides whether to migrate a container instance and to which target node. This unit maintains a migration cost assessment model that considers the following factors: the service interruption duration caused by container migration (related to the container's memory size and number of network connections), the target node's remaining resources, and the network latency between the source and target nodes. For each edge computing node, the migration decision unit calculates its load pressure index (LPI) using the formula: LPI = α × predicted CPU usage + β × predicted memory usage + γ × predicted network bandwidth usage, where α, β, and γ are weighting coefficients (default values are 0.4, 0.4, and 0.2, respectively). When a node's LPI exceeds a threshold (e.g., 0.8), the container migration process is triggered. To select a target node, the migration decision unit uses a multi-objective optimization algorithm to simultaneously minimize migration cost and load balancing. The specific steps are: first, candidate nodes whose remaining resources meet the container's resource requirements are screened; then, the migration benefit of each candidate node is calculated (the source node's LPI reduction minus the target node's LPI increase); and finally, the node with the highest migration benefit and lowest migration cost is selected as the target node. For migration decisions, a two-level confirmation mechanism is adopted: first, the algorithm generates a recommended migration plan, which is then submitted for manual review (which can be automatically executed in emergency situations).
[0159] The execution control unit is responsible for safely migrating container instances and updating resource allocations based on the results of the migration decision unit. This unit uses the container orchestration platform's API to perform migrations, employing a rolling update strategy to ensure service continuity. The specific process involves first creating a new container instance on the target node with the same configuration as the source container and waiting for the new container to start and complete initialization. Client traffic is then gradually switched from the source container to the new container (via a load balancer or service discovery mechanism). Finally, after confirming that the new container is functioning properly, the source container is stopped and deleted. During the migration, the execution control unit monitors service availability and performance metrics in real time. If an anomaly is detected (such as a drop in request success rate exceeding 10%), the migration is immediately rolled back to the source container. After the migration is complete, the execution control unit updates resource monitoring data and load prediction models, incorporating historical data on the new node's resource usage. It also adjusts prediction model parameters to improve future prediction accuracy. The execution control unit also records detailed migration logs, including migration time, migrated container information, source and target node information, and resource usage before and after the migration, for subsequent analysis and auditing.
[0160] In the overall operational process of the dynamic load balancing module, the resource monitoring unit continuously collects resource usage data from edge computing nodes. The load prediction unit uses this data to predict future load trends. The migration decision unit develops a container migration plan based on the predictions, and the execution control unit is responsible for implementing the migration safely and efficiently. These four units form a closed-loop feedback system, continuously adjusting load distribution based on real-time changes. For example, if an edge computing node experiences a sustained increase in CPU usage due to processing a large number of visual recognition tasks, the load prediction unit predicts that its LPI will exceed the threshold in 15 minutes. The migration decision unit then preemptively migrates some non-critical containers to other nodes. The execution control unit performs the migration during off-peak hours to ensure uninterrupted service. Through this dynamic adjustment, the system improves resource utilization while maintaining service availability, avoiding situations where some nodes are overloaded while others remain idle. The entire module design fully considers the characteristics of edge computing environments, such as limited node resources and unstable network connections. Through a prediction-driven proactive migration strategy, it effectively addresses the dynamic changes in multimodal data processing tasks, improving the overall performance and reliability of the smart doll system.
[0161] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus.
[0162] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.
Claims
1. A multimodal data processing task scheduling optimization system for intelligent dolls, characterized by: The system comprises: A multimodal acquisition module is used to acquire multimodal input data generated during the operation of the smart doll in real time; the multimodal input data includes a speech signal sequence, a visual image sequence, and an environmental sensor data stream; A task decomposition module is used to parse the multimodal input data into K parallel processing tasks according to a preset task type mapping table; the task type mapping table contains the correspondence between data modalities and processing tasks, and each record in the mapping table contains a data modality combination and a corresponding processing task type: single voice modality → voice recognition task; single visual modality → image classification task; voice + visual modality → audio-visual interaction task; voice + environmental sensor modality → environmental perception voice feedback task; vision + environmental sensor modality → visual navigation task; voice + vision + environmental sensor modality → multimodal scene understanding task; search for a matching modality combination in the task type mapping table, and if there is a completely matching record, generate the corresponding processing task; if there is no completely matching record, perform fuzzy matching according to the similarity of the modality combination; the task type mapping table sets a default task type, and when no record can be matched, generates a default general data processing task; A resource allocation module, configured to allocate an independently running container instance to each processing task based on the real-time load status of the computing node; the container instance includes a preconfigured runtime environment and computing resource quota; A scheduling execution module is used to distribute the container instance to the corresponding edge computing node according to a preset priority queue to perform calculations and synchronously receive calculation result data; A dynamic update module, configured to periodically adjust the execution weight coefficient of the priority queue according to the calculation result data; The scheduling execution module includes: A queue generation unit, configured to generate a priority sorting list including urgent task identifiers according to task processing timeliness requirements; A distribution control unit, configured to push the container instances to the task execution queue of the target edge computing node in sequence according to the priority sorting list; A status monitoring unit, which is used to capture the execution status of container instances in real time and record task completion timestamps; The feedback receiving unit is used to receive the calculation result data returned by the edge computing node through the asynchronous message channel.
2. The multimodal data processing task scheduling optimization system for intelligent dolls according to claim 1 is characterized in that: The task decomposition module includes: A feature extraction unit, configured to perform time-frequency feature analysis on the speech signal sequence to generate a speech feature vector set; An image segmentation unit, configured to perform dynamic target detection on the visual image sequence and generate an image region coordinate data set; a data fusion unit, configured to align the speech feature vector set, the image region coordinate data set, and the environmental sensor data stream according to timestamps to generate a synchronous fusion data packet; The task generating unit is configured to match the corresponding K processing tasks from the task type mapping table according to the data type of the synchronous fusion data packet.
3. The multimodal data processing task scheduling optimization system for intelligent dolls according to claim 1 is characterized in that: The resource allocation module includes: Node detection unit, used to obtain the available memory capacity and processor occupancy of edge computing nodes in real time; A resource prediction unit, used to predict the computing resource requirements of each processing task based on historical task execution time data; An instance configuration unit, configured to generate container configuration parameters including a memory limit and a core count for each processing task according to the computing resource requirements; An instance deployment unit is used to create an isolated container instance on an edge computing node whose load status meets the requirements according to the container configuration parameters.
4. The multimodal data processing task scheduling optimization system for intelligent dolls according to claim 1 is characterized in that: The dynamic update module includes: Weight calculation unit, used to count the historical average execution time and resource consumption of each task type; A coefficient adjustment unit, configured to dynamically attenuate and compensate the task weight coefficients in the priority queue according to the historical average execution time; The queue reconstruction unit is used to regenerate an optimized priority sorting list based on the updated weight coefficients.
5. A multimodal data processing task scheduling optimization method for intelligent dolls, characterized in that: The method comprises: Acquire multimodal input data generated during the operation of the smart doll in real time; the multimodal input data includes a speech signal sequence, a visual image sequence, and an environmental sensor data stream; Parse the multimodal input data into K parallel processing tasks according to a preset task type mapping table; the task type mapping table contains the correspondence between data modalities and processing tasks, and each record in the mapping table contains a data modality combination and a corresponding processing task type: single voice modality → voice recognition task; single visual modality → image classification task; voice + visual modality → audio-visual interaction task; voice + environmental sensor modality → environmental perception voice feedback task; vision + environmental sensor modality → visual navigation task; voice + vision + environmental sensor modality → multimodal scene understanding task; search for a matching modality combination in the task type mapping table, and if there is a completely matching record, generate the corresponding processing task; if there is no completely matching record, perform fuzzy matching according to the similarity of the modality combination; the task type mapping table sets a default task type, and when no record can be matched, generates a default general data processing task; Allocate an independently running container instance to each processing task based on the real-time load status of the computing node; the container instance includes a pre-configured runtime environment and computing resource quota; Distribute the container instance to the corresponding edge computing node according to the preset priority queue to perform calculations and synchronously receive the calculation result data; Periodically adjusting the execution weight coefficient of the priority queue according to the calculation result data; The step of parsing the multimodal input data into K parallel processing tasks according to a preset task type mapping table specifically includes: Performing time-frequency feature analysis on the speech signal sequence to generate a speech feature vector set; Performing dynamic target detection on the visual image sequence to generate an image region coordinate data set; Aligning the speech feature vector set, the image region coordinate data set, and the environmental sensor data stream according to timestamps to generate a synchronous fusion data packet; K corresponding processing tasks are matched from the task type mapping table according to the data type of the synchronous fusion data packet.
6. The multimodal data processing task scheduling optimization method for intelligent dolls according to claim 5 is characterized in that: The method of allocating an independent running container instance to each processing task based on the real-time load status of the computing node specifically includes: Obtain the available memory capacity and processor occupancy of edge computing nodes in real time; Predict the computing resource requirements of each processing task based on historical task execution time data; Generate container configuration parameters including memory limit and number of cores for each processing task according to the computing resource requirements; An isolated container instance is created on an edge computing node whose load status meets the requirements according to the container configuration parameters.
7. The multimodal data processing task scheduling optimization method for intelligent dolls according to claim 5 is characterized in that: The step of distributing the container instance to the corresponding edge computing node for execution according to the preset priority queue specifically includes: Generate a priority list including urgent task identifiers based on task processing timeliness requirements; Pushing the container instances to the task execution queue of the target edge computing node in sequence according to the priority sorting list; Capture the execution status of container instances in real time and record task completion timestamps; Receive the calculation result data returned by the edge computing node through the asynchronous message channel.
8. The multimodal data processing task scheduling optimization method for intelligent dolls according to claim 7 is characterized in that: The periodic adjustment of the execution weight coefficient of the priority queue according to the calculation result data specifically includes: Statistics on the historical average execution time and resource consumption of each task type; Performing dynamic attenuation compensation on the task weight coefficients in the priority queue according to the historical average execution time; Regenerate the optimized priority sorting list based on the updated weight coefficients.
Citation Information
Patent Citations
Edge adaptive control system based on multiple modes
CN118778454A
Edge computing scheduling method and system for heterogeneous multi-source sensor
CN119960950A