Method and device for dynamically scheduling SOME / IP service resources by AI

Abstract

The invention provides a method and device for dynamically scheduling SOME / IP service resources by AI, and the method comprises the steps: firstly deploying an acquisition agent at an SOME / IP node, and continuously collecting service request historical data and real-time system state data; constructing a training data set based on the collected data, defining a state space, an action space and a reward function of an AI scheduling model, and training to generate an initial scheduling strategy; then the trained AI model is integrated to SOME / IP middleware, when a service request arrives, real-time data is analyzed through the model, a scheduling decision is output, and resource allocation is executed; finally, decision execution performance is monitored, and performance data is collected and fed back to the model to iteratively update the optimization strategy. The problems of poor adaptability and low resource utilization rate of traditional static or simple dynamic scheduling can be solved, the service response speed and the resource utilization efficiency are improved, and vehicle-mounted and other multi-service scene requirements are met.

Description

Technical Field

[0001] This application relates to the field of vehicle service scheduling technology, and in particular to a method and apparatus for AI dynamic scheduling of SOME / IP service resources. Background Technology

[0002] As automotive electronic and electrical architecture evolves towards domain controllers and central computing platforms, the number of integrated functional services in in-vehicle systems (such as autonomous driving, intelligent navigation, in-vehicle entertainment, and ADAS advanced driver assistance systems) is growing exponentially. SOME / IP, as a service-oriented middleware protocol, has become a core standard for communication between in-vehicle services due to its scalability and flexibility, playing a crucial role in service discovery, message transmission, and resource coordination. Currently, the scheduling of SOME / IP service resources mainly relies on two traditional solutions: one is a static configuration strategy, which predefines the resource allocation ratio and priority of each service during the production phase and strictly follows fixed rules during runtime. For example, allocating a fixed proportion of CPU and memory resources to autonomous driving services and setting a lower request processing priority for entertainment services; the other is a simple dynamic adjustment mechanism, such as load threshold-based scheduling. When the CPU utilization of an ECU exceeds a preset threshold (e.g., 80%), the resources of low-priority services are temporarily transferred to high-priority services. However, this type of mechanism relies on a single indicator to trigger adjustments and lacks comprehensive consideration of the overall system state and service request characteristics.

[0003] However, traditional scheduling schemes face significant limitations in practical applications: On the one hand, static configurations cannot adapt to dynamic load changes in the vehicle system. For example, during peak hours, when navigation service requests surge or autonomous driving services require high-frequency processing of sensor data, pre-allocated resources may be insufficient, leading to increased response latency. Conversely, during off-peak hours, a large amount of resources remain idle, resulting in wasted hardware resources. On the other hand, fixed-priority or simple threshold scheduling struggles to balance the real-time demands of multiple services. Low-priority services may become "starved" due to high-priority services occupying resources for extended periods. Furthermore, as the number of services increases, the cost of manually maintaining static configurations rises significantly, making it difficult to support large-scale service deployments. In addition, existing schemes cannot learn historical request patterns (such as service request patterns during specific time periods). When faced with sudden requests (such as safety service calls during emergency braking) or system expansion (such as adding new vehicle V2X services), the adaptability and flexibility of scheduling strategies are insufficient, becoming a key bottleneck restricting the performance improvement of vehicle SOME / IP systems. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a method and apparatus for AI dynamic scheduling of SOME / IP service resources, which can solve the problems of poor adaptability and low resource utilization of traditional static or simple dynamic scheduling, improve service response speed and resource utilization efficiency, and adapt to the needs of multiple service scenarios such as vehicle.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a method for dynamically scheduling SOME / IP service resources using AI, comprising the following steps: Deploy a data collection agent on the SOME / IP node to continuously collect historical service request data and real-time system status data; A training dataset is constructed based on the collected data, the state space, action space and reward function of the AI ​​scheduling model are defined, and an initial scheduling strategy is generated through training. The trained AI model is integrated into the SOME / IP middleware. When a service request arrives, the AI ​​model analyzes the real-time service request and system status, outputs scheduling decisions, and executes the allocation of SOME / IP service resources. Monitor the actual execution performance of scheduling decisions, collect performance data and feed it back to the AI ​​model, and iteratively update the model based on the feedback data to optimize the scheduling strategy.

[0006] Secondly, embodiments of this application also provide an apparatus for AI-dynamic scheduling of SOME / IP service resources, the apparatus comprising: The collection module is used to deploy collection agents on SOME / IP nodes to continuously collect historical service request data and real-time system status data; The training module is used to build a training dataset based on the collected data, define the state space, action space and reward function of the AI ​​scheduling model, and generate an initial scheduling policy through training. The execution module is used to integrate the trained AI model into the SOME / IP middleware. When a service request arrives, the AI ​​model analyzes the real-time service request and system status, outputs scheduling decisions, and executes the allocation of SOME / IP service resources. The feedback module is used to monitor the actual execution performance of scheduling decisions, collect performance data and feed it back to the AI ​​model, and iterate and update the model based on the feedback data to optimize the scheduling strategy.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the AI ​​dynamic scheduling SOME / IP service resource method described in any of the first aspects.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the AI ​​dynamic scheduling SOME / IP service resource method described in any one of the first aspects.

[0009] The embodiments of this application have the following beneficial effects: By constructing a complete closed-loop technology system of "data acquisition - model training - dynamic scheduling - feedback optimization", the core pain points of existing SOME / IP service scheduling, such as rigid static configuration, high response latency of fixed priority scheduling, low resource utilization and complex large-scale deployment management, are effectively solved. Specifically, it uses AI models to analyze service request characteristics and system status in real time, dynamically outputting adaptive scheduling decisions. This ensures that critical services such as autonomous driving and safety control receive priority access to resources, significantly reducing average response time and tail latency. Furthermore, intelligent allocation reduces resource idleness and overload, greatly improving the overall utilization efficiency of hardware resources such as CPU and memory. Simultaneously, the AI ​​model has the ability to learn from historical data and iteratively optimize from real-time feedback, adapting to dynamic scenarios such as peak-hour request fluctuations and service expansion in vehicle systems, eliminating the need for frequent manual configuration adjustments. Moreover, its plug-in integrated design requires no modification to the existing SOME / IP protocol stack core logic, ensuring compatibility with mainstream vehicle ECU and middleware architectures. It can efficiently support large-scale deployments of various services such as navigation, entertainment, and ADAS, ultimately providing a service resource scheduling solution that combines real-time performance, intelligence, and scalability for fields such as automotive electronics that rely on the SOME / IP protocol, contributing to a dual improvement in overall system performance and operational efficiency. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating steps S101-S104 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application; Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application; Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application; Figure 7 This is a flowchart illustrating steps S701-S703 provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the device for AI dynamic scheduling of SOME / IP service resources provided in the embodiments of this application; Figure 9 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0018] See Figure 1 , Figure 1 This is a flowchart illustrating steps S101-S104 of the AI ​​dynamic scheduling of SOME / IP service resources provided in this application embodiment, which will be combined with... Figure 1 Steps S101-S104 are explained below.

[0019] In step S101, a data collection agent is deployed on the SOME / IP node to continuously collect historical service request data and real-time system status data; Deploy a lightweight data collection agent (which can be implemented as a background process written in C++, consuming less than 5% of the total system resources to avoid impacting core service operation) on SOME / IP nodes (such as vehicle ECUs and edge computing nodes) to continuously collect two types of key data: first, historical service request data (recording the entire lifecycle information of service calls, providing a basis for AI models to learn request patterns); and second, real-time system status data (reflecting the current resource occupancy, ensuring that scheduling decisions align with actual resource capabilities). The core function of this step is to build the data foundation for AI scheduling, preventing decision-making biases caused by data gaps.

[0020] In step S102, a training dataset is constructed based on the collected data, the state space, action space and reward function of the AI ​​scheduling model are defined, and an initial scheduling strategy is generated through training. Here, a training dataset is constructed based on a mixture of historical and real-time data (using time-series partitioning, with a 7:3 ratio between training and validation sets to ensure data timeliness and generalization). By defining a state space (describing the environmental information during scheduling), an action space (defining the scheduling operations that the model can execute), and a reward function (clarifying the model's optimization objective), the AI ​​model learns how to select the optimal scheduling action based on the current state. The initial scheduling strategy generated during training must be tested on the validation set to ensure that the average response time is reduced by at least 20% compared to static scheduling before proceeding to subsequent stages. This step is the core of achieving intelligent scheduling, breaking through the rigidity of traditional fixed-rule scheduling.

[0021] In step S103, the trained AI model is integrated into the SOME / IP middleware. When a service request arrives, the AI ​​model analyzes the real-time service request and system status, outputs scheduling decisions, and executes the allocation of SOME / IP service resources. Here, the trained AI model is integrated into the SOME / IP middleware as a plugin (compatible with the SOME / IP protocol stack under the AUTOSAR architecture, requiring no modification to existing protocol logic and reducing deployment costs). When a service request arrives (such as a route planning request for in-vehicle navigation or an audio playback request for entertainment services), the model analyzes request characteristics (such as service type and urgency) and system status (such as ECU CPU load and remaining memory) in real time, outputs a scheduling decision, and the middleware executes resource allocation. This step achieves real-time response, ensuring that scheduling decisions are synchronized with dynamic system changes and avoiding resource overload or idleness.

[0022] In step S104, the actual execution performance of the scheduling decision is monitored, performance data is collected and fed back to the AI ​​model, and the model is iteratively updated based on the feedback data to optimize the scheduling strategy.

[0023] Finally, the monitoring module (a monitoring component that can be integrated into the SOME / IP middleware) collects the execution results of scheduling decisions in real time (such as whether the actual response time meets expectations and whether the system throughput meets the standards). This performance data is then fed back to the AI ​​model, triggering iterative updates (such as adjusting network weights and optimizing reward function parameters). This step forms a closed-loop learning mechanism, addressing the problem that existing scheduling algorithms cannot adapt to long-term load changes (such as fluctuations in request volume during peak hours in vehicle systems), ensuring long-term stable scheduling performance.

[0024] In some embodiments, see Figure 2 , Figure 2This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application. The specific steps for collecting historical service request data and real-time system status data include steps S201-S203, which will be explained in conjunction with each step.

[0025] In step S201, historical service request data is collected, and the data includes at least the service ID, request timestamp, request size, and expected delay. In step S202, real-time system status data is collected, including at least CPU utilization, memory usage, network bandwidth, and request queue length. In step S203, the two types of data collected are associated and stored to form a complete scheduling analysis dataset.

[0026] Service IDs are used to distinguish different types of SOME / IP services (e.g., Nav_001 for navigation services and ADAS_002 for autonomous driving services), ensuring the model can identify service categories. Request timestamps are used to analyze the time distribution patterns of requests (e.g., a surge in navigation requests from 7:00 to 9:00 for in-vehicle systems), providing a basis for time-based scheduling optimization. Request size (e.g., the number of bytes in the request data packet) is used to determine the service's network bandwidth requirements (e.g., a high-definition map download request size of 10MB requires priority allocation of bandwidth resources). Expected latency (e.g., autonomous driving services require a latency ≤100ms) is used to define the service's real-time requirements, providing a reference for the model to determine service priorities. During data collection, it is necessary to ensure that the data sampling frequency is not less than once per second to avoid missing critical request information.

[0027] CPU utilization reflects the usage of computing resources (e.g., when the CPU utilization of the ECU reaches 80%, new service allocation should be reduced to avoid lag); memory usage is used to determine whether memory resources are sufficient (e.g., when memory usage reaches 90%, memory for low-priority services should be released first); network bandwidth reflects data transmission capacity (e.g., when the remaining in-vehicle Ethernet bandwidth is 20Mbps, high-traffic non-critical services should be restricted); request queue length is used to determine the congestion level of service requests (e.g., when the queue length exceeds 50 requests, an overload scheduling strategy should be triggered). Data collection must be performed through system call interfaces (e.g., the `top` command in Linux systems, or the dedicated monitoring interface of the in-vehicle ECU) to ensure data accuracy error ≤5%.

[0028] The collected data is associated with timestamps and service IDs (e.g., a navigation service request at 08:30:00 on 2024-10-01 is linked with CPU utilization and memory usage data of ECU1 at the same timestamp), and stored in a time-series database (such as InfluxDB, which supports high-concurrency writes and time-series queries) to form a scheduling analysis dataset containing request-state correspondences. The purpose of this associated storage is to allow the AI ​​model to learn the correlation between specific service requests and system states (e.g., when a navigation request arrives, a CPU utilization exceeding 70% will lead to a significant increase in latency), providing complete sample data for subsequent model training.

[0029] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application. After deploying a collection agent on the SOME / IP node to continuously collect historical service request data and real-time system status data, and before constructing a training dataset based on the collected data, defining the state space, action space, and reward function of the AI ​​scheduling model, and generating the initial scheduling strategy through training, it also includes data preprocessing steps S301-S303, which will be explained in conjunction with each step.

[0030] In step S301, the collected dataset is cleaned to remove outliers and missing values; In step S302, the cleaned data is normalized, and the service type is encoded as a one-hot vector; In step S303, the system state index is scaled to the [0,1] interval to construct a feature vector for model training.

[0031] The collected data may contain outliers (such as CPU utilization of 150% due to sensor malfunction, or negative request sizes) or missing values ​​(such as missing timestamps for some requests due to network fluctuations). These must be handled as follows: For outliers, use the 3σ principle for identification (if the data exceeds the mean ± 3 times the standard deviation, it is considered an outlier) and replace it with the median of that field (e.g., replace 150% CPU utilization with the median CPU utilization of 40% for the same period). For missing values, if the missing percentage is ≤5%, use linear interpolation to fill in the gaps (e.g., if memory usage for a certain timestamp is missing, calculate the average of memory usage for adjacent timestamps to fill in the gaps). If the missing percentage is >5%, remove the complete data sample for that time period to avoid affecting model training. After data cleaning, ensure that the percentage of valid data samples is ≥95%.

[0032] SOME / IP service types are text or enumeration types (such as navigation services and entertainment services), which cannot be directly input into the AI ​​model. They need to be converted through one-hot vector encoding (e.g., if the system contains 3 types of services, navigation service is encoded as [1,0,0], entertainment service as [0,1,0], and autonomous driving service as [0,0,1]). The encoding process requires establishing a service type-vector mapping table, which is stored in the model configuration file to ensure that the model can accurately identify the service type through the vector, providing a basis for subsequent priority judgment.

[0033] The numerical ranges of different system state indicators vary considerably (e.g., CPU utilization 0-100%, memory usage 0-8GB). Directly inputting these indicators into the model would result in large values ​​(e.g., memory usage) having an excessive impact on the model's decisions. Therefore, all system state indicators need to be scaled to the [0,1] range. This is achieved using a min-max normalization formula. After normalization, the influence weights of each indicator on the model are balanced, ensuring more objective model decisions.

[0034] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application. The specific steps for training the AI ​​scheduling model include steps S401-S404, which will be explained in conjunction with each step.

[0035] In step S401, a deep reinforcement learning model is selected as the AI ​​scheduling model, specifically the deep Q-network (DQN) model. In step S402, the state space of the model is defined as a set of current request queue characteristics and system load indicators, and the action space is a set of executable scheduling operations. In step S403, a reward function is designed, which is constructed based on negative response time or system throughput; In step S404, historical data is used to simulate the training environment, and the network weights are iteratively updated through Q-learning until the model converges, ensuring that the training objective is to minimize the average service response time.

[0036] Here, a deep reinforcement learning model (rather than traditional machine learning models such as decision trees and neural networks) is chosen because reinforcement learning learns the optimal strategy through trial and error in the interaction between the agent and the environment, which is more suitable for the dynamic nature of SOME / IP service scheduling (such as real-time load changes and random service request types). Specifically, a deep Q-network (DQN) model is adopted because DQN solves the problem of training instability in high-dimensional state spaces (such as SOME / IP systems containing multiple ECUs and services, with state dimensions reaching tens of dimensions) by using experience replay (storing historical interaction samples and randomly sampling for training) and a target network (fixing the target Q value for a period of time to avoid training oscillations). This ensures that the model can converge to the optimal scheduling strategy.

[0037] The state space is defined as a set of current request queue characteristics and system load indicators, specifically including: the number of each service in the request queue (e.g., 5 navigation requests, 3 entertainment requests), the CPU utilization of each ECU, the memory usage of each ECU, and the remaining network bandwidth, totaling 2N+M+1 dimensions (N is the number of service types, and M is the number of ECUs). The definition of the state space must fully reflect the environmental information during scheduling to ensure that the model can comprehensively judge the current system status.

[0038] The action space is defined as a set of executable scheduling operations, specifically including: adjusting service priorities (e.g., raising the priority of the navigation service from medium to high), setting resource allocation ratios (e.g., allocating 60% of CPU resources to the autonomous driving service), ECU node routing (e.g., routing entertainment requests to ECU2), and adjusting the number of service instances (e.g., increasing the number of navigation service instances from 2 to 3). The definition of the action space must cover the core operations of SOME / IP service scheduling to ensure that the model can achieve optimal resource allocation through different combinations of actions.

[0039] The reward function is the core of guiding the model's learning objective, and it needs to simultaneously consider both low latency and high resource utilization. Therefore, a design based on negative response time plus throughput correction term is adopted: R = -T + α × S, where R is the reward value, T is the actual service response time (the longer the response time, the lower the reward value, guiding the model to reduce latency), α is the correction coefficient (ranging from 0.1 to 0.3, balancing the weights of latency and throughput), and S is the system throughput (the higher the throughput, the higher the reward value, guiding the model to improve resource utilization). For example, if a scheduling action results in a service response time T = 200ms, a system throughput S = 100 requests / second, and α = 0.2, then the reward value R = -200 + 0.2 × 100 = -180; if another action results in T = 150ms and S = 90, then R = -150 + 0.2 × 90 = -132. The latter has a higher reward value, and the model will prioritize learning the latter action.

[0040] The model training process is as follows: Initialization: Construct a simulated training environment (based on collected historical data, reproduce service requests and system state changes under different load scenarios), initialize the DQN main network (for outputting the current Q value) and target network (for outputting the target Q value), set the learning rate to 0.001, and the experience replay buffer capacity to 100,000 samples.

[0041] Interaction and Sampling: The model interacts with service requests and system states in a simulated environment, generating state-action-reward-next state samples, which are stored in the experience replay buffer. When the number of samples in the buffer reaches 1000, random sampling begins (32 samples each time) to avoid training bias caused by sample correlation.

[0042] Weight update: Based on the sampled samples, the target Q value is calculated using the temporal difference algorithm, and the main network weights are updated using the mean squared error loss function (MSE). Every 1000 training steps, the main network weights are copied to the target network to ensure the stability of the target Q value.

[0043] Convergence Validation: After every 10,000 training steps, the model performance is tested using a validation set. If the average response time fluctuation of three consecutive validations is ≤5% and the resource utilization rate is ≥80%, the model is considered to have converged and training is stopped; otherwise, the learning rate or reward function parameters are adjusted and training continues.

[0044] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application. The specific steps for performing dynamic scheduling include steps S501-S504, which will be explained in conjunction with each step.

[0045] In step S501, when the system starts, the AI ​​model is integrated into the SOME / IP middleware as a plug-in to establish a real-time data interaction channel between the model and the middleware. In step S502, when a new service request arrives, the request features and current system status data are extracted and input into the AI ​​model; In step S503, the AI ​​model infers and outputs a scheduling decision, which includes at least one of the following: service priority adjustment, resource allocation ratio setting, ECU node routing of service requests, and service instance quantity control. In step S504, the SOME / IP middleware performs service resource allocation operations based on the scheduling decision.

[0046] Here, a plug-in integration approach is adopted, encapsulating the trained AI model (exported in ONNX format, supporting cross-language calls) into a scheduling plug-in of the SOME / IP middleware. Data interaction is achieved through the extended interfaces provided by the middleware (such as the Service Discovery extended interface defined by AUTOSAR): the middleware pushes service request data and system status data to the plug-in in real time, and the plug-in returns the scheduling decision to the middleware after invoking the AI ​​model for inference. This integration method does not require modification of the core logic of the existing SOME / IP protocol stack (such as service registration and message transmission), has strong compatibility, and can be adapted to mainstream automotive SOME / IP middleware (such as Vector's SOME / IP Stack and EB's EB tresos), shortening the deployment cycle to 1-2 weeks.

[0047] When a new service request arrives (such as a user initiating a navigation route query), the middleware first extracts the request characteristics (obtaining the service ID by parsing the SOME / IP message header, obtaining the request size through the message body, and obtaining the expected latency by combining preset service attributes). Simultaneously, it obtains the current system status (CPU utilization, memory usage, network bandwidth, and request queue length for each ECU) through the system monitoring interface. The request characteristics and system status data are then converted into vectors conforming to the model input format (e.g., encoding the service type as a one-hot vector and normalizing system status indicators to the [0,1] range), and input into the AI ​​model plugin. The data extraction and conversion time must be ≤10ms to ensure the real-time nature of scheduling decisions.

[0048] The AI ​​model outputs specific scheduling decisions through reasoning (based on pre-trained weights, performing forward computation on the input vector): If it is a service priority adjustment, the priority level will be output (e.g., high, medium, low, corresponding to values ​​of 1, 0.5, 0, and the middleware will process requests in priority order). If a resource allocation ratio is set, the CPU and memory allocation ratios for each service will be output (e.g., allocate 50% CPU and 40% memory to the autonomous driving service). If it is an ECU node route, the ID of the target ECU will be output (e.g., ECU2, the middleware will forward the request to that ECU). If adjusting the number of service instances, output the number of instances for the target service (e.g., increasing the number of navigation service instances from 2 to 3, the middleware starts new service instances). Model inference time must be ≤20ms to ensure no additional latency is added to service requests.

[0049] Based on the scheduling decisions output by the AI ​​model, the SOME / IP middleware calls the corresponding resource management module to execute operations: For priority adjustment, the middleware modifies the sorting rules of the request queue (high-priority requests are inserted at the head of the queue, and low-priority requests are inserted at the tail). Regarding resource allocation ratios, the middleware limits the CPU and memory usage limits of each service through the operating system's resource scheduling interface (such as Linux's cgroups); For ECU node routing, the middleware modifies the SOME / IP service discovery mechanism to point the requested service instance address to the target ECU; For service instance control, the middleware starts or stops service instances through process management interfaces (such as systemd). The execution time must be ≤30ms to ensure that resource allocation takes effect quickly and avoid service request timeouts.

[0050] In some embodiments, see Figure 6 , Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application. The specific steps for implementing feedback optimization include steps S601-S604, which will be explained in conjunction with each step.

[0051] In step S601, the execution process of the scheduling decision is monitored in real time, and the actual response time and system throughput are collected as performance data. In step S602, an update trigger condition is set, wherein the condition is for processing a preset number of service requests or every preset time interval; In step S603, when the triggering condition is met, the performance data is input into the AI ​​model, and the model parameters are fine-tuned using an online learning algorithm. In step S604, the scheduling performance of the fine-tuned model is verified. If the performance meets the standard, the model is updated; otherwise, the parameters are readjusted and verified again.

[0052] Here, two types of core performance data are collected in real time through a monitoring component integrated into the SOME / IP middleware: Actual response time: From the time the service request arrives at the middleware to the time the middleware returns the response result, the total time is recorded (accurate to the millisecond level) and categorized by service type (such as the average response time of navigation services and the tail latency of autonomous driving services). System throughput: This measures the number of service requests successfully processed by the middleware per unit time (unit: requests / second), while also recording the resource utilization of each ECU (average CPU utilization and memory usage). Performance data is collected once per second and stored in a monitoring database (such as Prometheus), supporting real-time querying and historical trend analysis.

[0053] Set both request quantity trigger and time trigger conditions to ensure that the model updates in a timely manner when the request volume accumulates to a certain scale or the time interval reaches a threshold, thus balancing update frequency and system overhead. Request Count Trigger: A model update is triggered every 1000-5000 service requests processed (this can be dynamically adjusted based on the system's request volume, such as 1000 during peak hours and 5000 during off-peak hours). Time-triggered: If the request volume is low and does not reach the request quantity threshold for an extended period, an update will be forcibly triggered every 1-2 hours (2 hours for in-vehicle systems where request volume is low at night). The triggering conditions are set via configuration files, allowing users to adjust them according to their specific scenarios.

[0054] When the triggering conditions are met, the performance data and corresponding scheduling decisions and system status data from the most recent triggering cycle are extracted from the monitoring database to form a fine-tuning dataset (sample size ≥ 1000); the AI ​​model is then fine-tuned using incremental learning. Load the currently used model weights as initial weights; use the fine-tuning dataset as training samples, setting a low learning rate (0.0001, to avoid forgetting existing knowledge), and train for 100-200 steps; employ a combination of experience replay and online sampling, adding newly generated samples to the experience replay buffer while retaining historical samples (historical samples account for ≥70% of the buffer), ensuring the model learns both new patterns and historical experience simultaneously. The fine-tuning process should take ≤30 seconds to avoid impacting normal service scheduling.

[0055] After fine-tuning, performance needs to be verified through two steps: offline verification and online gray-scale testing. First, simulate load scenarios using historical data from the last hour, comparing the average response time, resource utilization, and tail latency (e.g., latency of 99% of requests) before and after fine-tuning. If the average response time decreases by ≥5% or resource utilization increases by ≥3% after fine-tuning, and tail latency does not increase, proceed to online testing. Then, deploy the fine-tuned model to a subset of ECUs (e.g., 10% of ECU nodes), handling only service requests from these nodes, and continuously monitor for 10 minutes. If no scheduling anomalies occur (e.g., request timeouts, resource overload), update the model to all ECUs. If the verification fails, roll back to the model before fine-tuning, analyze the reasons for performance degradation (e.g., data anomalies, improper parameter settings), and fine-tune again.

[0056] In some embodiments, see Figure 7 , Figure 7 This is a flowchart illustrating steps S701-S703 provided in the embodiments of this application. Before integrating the trained AI model into the SOME / IP middleware, it also includes service registration steps S701-S703, which will be explained in conjunction with each step.

[0057] In step S701, after the system starts, each SOME / IP service sends a registration request to the SOME / IP middleware; In step S702, each service submits a resource requirement profile during registration. The profile includes the maximum CPU utilization, memory requirements, and expected response latency threshold required for the service to run. In step S703, the SOME / IP middleware stores the registration information and resource requirement profiles of each service, providing data support for subsequent dynamic scheduling.

[0058] Here, after the system starts (such as during vehicle system power-on initialization or after the SOME / IP middleware starts), each SOME / IP service (such as navigation service, entertainment service, autonomous driving service, and ADAS service) initiates a registration request to the middleware through the SOME / IP ServiceRegistration protocol: the server (such as the navigation service process) sends a registration message to the middleware's service registration module, the message containing basic information such as service ID, service instance ID, service type, and network address (IP + port); after receiving the registration request, the middleware returns a registration confirmation message to ensure that the service and the middleware establish a communication connection. The registration process must comply with the SOME / IP protocol specification (such as AUTOSAR_SWS_SOMEIPProtocol) to ensure that services from different manufacturers can register compatiblely.

[0059] When registering, each service must submit a resource requirement profile (encapsulated in JSON format, containing the following core fields): Maximum CPU utilization: The maximum percentage of CPU resources that the service is allowed to use during runtime (e.g., for autonomous driving services that require real-time processing of sensor data, the maximum CPU utilization is set to 70%; for entertainment services that have low real-time requirements, it is set to 30%). Memory requirements: Minimum and maximum memory required for the service to run (e.g., for navigation services that need to load map data, the minimum memory is set to 512MB and the maximum memory is set to 2GB). Expected response latency threshold: The maximum acceptable response time for the service (e.g., for control command requests in autonomous driving services, the latency threshold is set to 100ms; for audio playback requests in entertainment services, the threshold is set to 500ms). Resource requirement profiles must be set by the service developers based on the service's functional characteristics and performance test results to ensure that the values ​​accurately reflect the service's resource requirements (e.g., determining the peak CPU utilization of the service under full load through stress testing).

[0060] The SOME / IP middleware stores the registration information (service ID, network address) and resource requirement profiles of each service in a service information database (using an SQLite database for fast querying), and establishes a mapping index between service IDs and resource requirements. During subsequent dynamic scheduling, the AI ​​model can quickly query the corresponding resource requirement profile using the service ID. For example, when receiving an autonomous driving service request, the model finds its latency threshold to be 100ms, and therefore prioritizes resource allocation during scheduling to ensure the response time does not exceed the threshold. When the CPU utilization of an ECU reaches 70% (the maximum CPU utilization for autonomous driving services), the model will avoid allocating new autonomous driving requests to that ECU to prevent resource overload. Registration information must be updated in real time (e.g., re-registering after a service restart, or submitting update requests when service resource requirements change) to ensure that the information stored in the middleware is consistent with the actual service status.

[0061] In summary, the embodiments of this application have the following beneficial effects: By constructing a complete closed-loop technology system of "data acquisition - model training - dynamic scheduling - feedback optimization", the core pain points of existing SOME / IP service scheduling, such as rigid static configuration, high response latency of fixed priority scheduling, low resource utilization and complex large-scale deployment management, are effectively solved. Specifically, it uses AI models to analyze service request characteristics and system status in real time, dynamically outputting adaptive scheduling decisions. This ensures that critical services such as autonomous driving and safety control receive priority access to resources, significantly reducing average response time and tail latency. Furthermore, intelligent allocation reduces resource idleness and overload, greatly improving the overall utilization efficiency of hardware resources such as CPU and memory. Simultaneously, the AI ​​model has the ability to learn from historical data and iteratively optimize from real-time feedback, adapting to dynamic scenarios such as peak-hour request fluctuations and service expansion in vehicle systems, eliminating the need for frequent manual configuration adjustments. Moreover, its plug-in integrated design requires no modification to the existing SOME / IP protocol stack core logic, ensuring compatibility with mainstream vehicle ECU and middleware architectures. It can efficiently support large-scale deployments of various services such as navigation, entertainment, and ADAS, ultimately providing a service resource scheduling solution that combines real-time performance, intelligence, and scalability for fields such as automotive electronics that rely on the SOME / IP protocol, contributing to a dual improvement in overall system performance and operational efficiency.

[0062] Based on the same inventive concept, this application also provides an apparatus for dynamically scheduling SOME / IP service resources, which corresponds to the method for dynamically scheduling SOME / IP service resources in the first embodiment. Since the principle of the apparatus in this application is similar to the above-mentioned method for dynamically scheduling SOME / IP service resources, the implementation of the apparatus can refer to the implementation of the method, and the repeated parts will not be described again.

[0063] like Figure 8 As shown, Figure 8 This is a schematic diagram of the structure of the AI-dynamic scheduling device 800 for SOME / IP service resources provided in this application embodiment. The AI-dynamic scheduling device 800 for SOME / IP service resources includes: The collection module 801 is used to deploy a collection agent on the SOME / IP node to continuously collect historical service request data and real-time system status data; Training module 802 is used to build a training dataset based on the collected data, define the state space, action space and reward function of the AI ​​scheduling model, and generate an initial scheduling policy through training; The execution module 803 is used to integrate the trained AI model into the SOME / IP middleware. When a service request arrives, the AI ​​model analyzes the real-time service request and system status, outputs scheduling decisions, and executes the allocation of SOME / IP service resources. Feedback module 804 is used to monitor the actual execution performance of scheduling decisions, collect performance data and feed it back to the AI ​​model, and iteratively update the model based on the feedback data to optimize the scheduling strategy.

[0064] Those skilled in the art should understand that Figure 8 The implementation functions of each unit in the AI ​​dynamic scheduling SOME / IP service resource apparatus 800 shown can be understood with reference to the relevant description of the aforementioned AI dynamic scheduling SOME / IP service resource method. Figure 8 The functions of each unit in the AI ​​dynamic scheduling SOME / IP service resource device 800 shown can be implemented by a program running on a processor or by specific logic circuits.

[0065] In one possible implementation, the specific steps for collecting historical service request data and real-time system status data include: Collect historical service request data, which includes at least the service ID, request timestamp, request size, and expected delay. Collect real-time system status data, which includes at least CPU utilization, memory usage, network bandwidth, and request queue length; The two types of data collected are associated and stored to form a complete scheduling analysis dataset.

[0066] In one possible implementation, after deploying a collection agent on the SOME / IP node to continuously collect historical service request data and real-time system status data, and before constructing a training dataset based on the collected data, defining the state space, action space, and reward function of the AI ​​scheduling model, and generating the initial scheduling strategy through training, a data preprocessing step is also included. Specific steps include: The collected dataset is cleaned to remove outliers and missing values; The cleaned data is normalized, and the service type is encoded as a one-hot vector; The system state indicators are scaled to the [0,1] interval to construct feature vectors for model training.

[0067] In one possible implementation, the specific steps for training the AI ​​scheduling model include: A deep reinforcement learning model was chosen as the AI ​​scheduling model, specifically the Deep Q-Network (DQN) model. The state space of the model is defined as the set of current request queue characteristics and system load indicators, and the action space is the set of executable scheduling operations. Design a reward function, which is constructed based on negative response time or system throughput; The training environment is simulated using historical data, and the network weights are iteratively updated through Q-learning until the model converges, ensuring that the training objective is to minimize the average service response time.

[0068] In one possible implementation, the specific steps for performing dynamic scheduling include: When the system starts, the AI ​​model is integrated into the SOME / IP middleware as a plug-in to establish a real-time data interaction channel between the model and the middleware. When a new service request arrives, extract the request characteristics and current system status data, and input them into the AI ​​model; The AI ​​model infers and outputs scheduling decisions, which include at least one of the following: service priority adjustment, resource allocation ratio setting, ECU node routing of service requests, and service instance number control. The SOME / IP middleware performs service resource allocation operations based on scheduling decisions.

[0069] In one possible implementation, the specific steps for achieving feedback optimization include: Monitor the execution process of scheduling decisions in real time and collect actual response time and system throughput as performance data; Set update trigger conditions, wherein the conditions are for processing a preset number of service requests or every preset time interval; When the triggering conditions are met, performance data is input into the AI ​​model, and online learning algorithms are used to fine-tune the model parameters. Verify the scheduling performance of the fine-tuned model. If the performance meets the requirements, update the model; otherwise, readjust the parameters and verify again.

[0070] In one possible implementation, a service registration step is included before integrating the trained AI model into the SOME / IP middleware. The specific steps include: After the system starts up, each SOME / IP service sends a registration request to the SOME / IP middleware; When registering, each service submits a resource requirement profile, which includes the maximum CPU utilization, memory requirements, and expected response latency threshold required for the service to run. The SOME / IP middleware stores the registration information and resource requirement profiles of each service, providing data support for subsequent dynamic scheduling.

[0071] The aforementioned AI-powered SOME / IP service resource scheduling device effectively addresses core pain points in existing SOME / IP service scheduling, such as rigid static configuration, high response latency of fixed priority scheduling, low resource utilization, and complex large-scale deployment and management, by constructing a complete closed-loop technical system of "data acquisition - model training - dynamic scheduling - feedback optimization". Specifically, it uses AI models to analyze service request characteristics and system status in real time, dynamically outputting adaptive scheduling decisions. This ensures that critical services such as autonomous driving and safety control receive priority access to resources, significantly reducing average response time and tail latency. Furthermore, intelligent allocation reduces resource idleness and overload, greatly improving the overall utilization efficiency of hardware resources such as CPU and memory. Simultaneously, the AI ​​model has the ability to learn from historical data and iteratively optimize from real-time feedback, adapting to dynamic scenarios such as peak-hour request fluctuations and service expansion in vehicle systems, eliminating the need for frequent manual configuration adjustments. Moreover, its plug-in integrated design requires no modification to the existing SOME / IP protocol stack core logic, ensuring compatibility with mainstream vehicle ECU and middleware architectures. It can efficiently support large-scale deployments of various services such as navigation, entertainment, and ADAS, ultimately providing a service resource scheduling solution that combines real-time performance, intelligence, and scalability for fields such as automotive electronics that rely on the SOME / IP protocol, contributing to a dual improvement in overall system performance and operational efficiency.

[0072] like Figure 9 As shown, Figure 9 This is a schematic diagram of the composition structure of the electronic device 900 provided in the embodiments of this application. The electronic device 900 includes: The device 900 includes a processor 901, a storage medium 902, and a bus 903. The storage medium 902 stores machine-readable instructions executable by the processor 901. When the electronic device 900 is running, the processor 901 communicates with the storage medium 902 via the bus 903. The processor 901 executes the machine-readable instructions to perform the steps of the AI ​​dynamic scheduling SOME / IP service resource method described in the embodiments of this application.

[0073] In practical applications, the various components in the electronic device 900 are coupled together via a bus 903. It is understood that the bus 903 is used to achieve communication between these components. In addition to a data bus, the bus 903 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general designated all buses as Bus 903.

[0074] The aforementioned electronic devices effectively address core pain points in existing SOME / IP service scheduling, such as rigid static configuration, high response latency of fixed priority scheduling, low resource utilization, and complex large-scale deployment and management, by constructing a complete closed-loop technical system of "data acquisition - model training - dynamic scheduling - feedback optimization". Specifically, it uses AI models to analyze service request characteristics and system status in real time, dynamically outputting adaptive scheduling decisions. This ensures that critical services such as autonomous driving and safety control receive priority access to resources, significantly reducing average response time and tail latency. Furthermore, intelligent allocation reduces resource idleness and overload, greatly improving the overall utilization efficiency of hardware resources such as CPU and memory. Simultaneously, the AI ​​model has the ability to learn from historical data and iteratively optimize from real-time feedback, adapting to dynamic scenarios such as peak-hour request fluctuations and service expansion in vehicle systems, eliminating the need for frequent manual configuration adjustments. Moreover, its plug-in integrated design requires no modification to the existing SOME / IP protocol stack core logic, ensuring compatibility with mainstream vehicle ECU and middleware architectures. It can efficiently support large-scale deployments of various services such as navigation, entertainment, and ADAS, ultimately providing a service resource scheduling solution that combines real-time performance, intelligence, and scalability for fields such as automotive electronics that rely on the SOME / IP protocol, contributing to a dual improvement in overall system performance and operational efficiency.

[0075] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 901, the method for dynamically scheduling SOME / IP service resources using AI described in this application is implemented.

[0076] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0077] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0078] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0079] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0080] The aforementioned computer-readable storage medium effectively addresses the core pain points of existing SOME / IP service scheduling, such as rigid static configuration, high response latency of fixed priority scheduling, low resource utilization, and complex large-scale deployment and management, by constructing a complete closed-loop technical system of "data acquisition-model training-dynamic scheduling-feedback optimization". Specifically, it uses AI models to analyze service request characteristics and system status in real time, dynamically outputting adaptive scheduling decisions. This ensures that critical services such as autonomous driving and safety control receive priority access to resources, significantly reducing average response time and tail latency. Furthermore, intelligent allocation reduces resource idleness and overload, greatly improving the overall utilization efficiency of hardware resources such as CPU and memory. Simultaneously, the AI ​​model has the ability to learn from historical data and iteratively optimize from real-time feedback, adapting to dynamic scenarios such as peak-hour request fluctuations and service expansion in vehicle systems, eliminating the need for frequent manual configuration adjustments. Moreover, its plug-in integrated design requires no modification to the existing SOME / IP protocol stack core logic, ensuring compatibility with mainstream vehicle ECU and middleware architectures. It can efficiently support large-scale deployments of various services such as navigation, entertainment, and ADAS, ultimately providing a service resource scheduling solution that combines real-time performance, intelligence, and scalability for fields such as automotive electronics that rely on the SOME / IP protocol, contributing to a dual improvement in overall system performance and operational efficiency.

[0081] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0082] The modules described as separate components may or may not be physically separate. The components shown as modules 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 this embodiment according to actual needs.

[0083] 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.

[0084] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a 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, ROM, RAM, magnetic disks, or optical disks.

[0085] 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 dynamically scheduling SOME / IP service resources using AI, characterized in that, Includes the following steps: Deploy a data collection agent on the SOME / IP node to continuously collect historical service request data and real-time system status data; A training dataset is constructed based on the collected data, the state space, action space and reward function of the AI ​​scheduling model are defined, and an initial scheduling strategy is generated through training. The trained AI model is integrated into the SOME / IP middleware. When a service request arrives, the AI ​​model analyzes the real-time service request and system status, outputs scheduling decisions, and executes the allocation of SOME / IP service resources. Monitor the actual execution performance of scheduling decisions, collect performance data and feed it back to the AI ​​model, and iteratively update the model based on the feedback data to optimize the scheduling strategy.

2. The method for dynamically scheduling SOME / IP service resources using AI according to claim 1, characterized in that, The specific steps for collecting historical service request data and real-time system status data include: Collect historical service request data, which includes at least the service ID, request timestamp, request size, and expected delay. Collect real-time system status data, which includes at least CPU utilization, memory usage, network bandwidth, and request queue length; The two types of data collected are associated and stored to form a complete scheduling analysis dataset.

3. The method for dynamically scheduling SOME / IP service resources using AI according to claim 1, characterized in that, After deploying a data collection agent on the SOME / IP node to continuously collect historical service request data and real-time system status data, and before building a training dataset based on the collected data, defining the state space, action space, and reward function of the AI ​​scheduling model, and generating the initial scheduling strategy through training, a data preprocessing step is also included. Specific steps include: The collected dataset is cleaned to remove outliers and missing values; The cleaned data is normalized, and the service type is encoded as a one-hot vector; The system state indicators are scaled to the [0,1] interval to construct feature vectors for model training.

4. The method for dynamically scheduling SOME / IP service resources using AI according to claim 1, characterized in that, The specific steps for training an AI scheduling model include: A deep reinforcement learning model was chosen as the AI ​​scheduling model, specifically the Deep Q-Network (DQN) model. The state space of the model is defined as the set of current request queue characteristics and system load indicators, and the action space is the set of executable scheduling operations. Design a reward function that is constructed based on negative response time or system throughput; The training environment is simulated using historical data, and the network weights are iteratively updated through Q-learning until the model converges, ensuring that the training objective is to minimize the average service response time.

5. The method for dynamically scheduling SOME / IP service resources using AI according to claim 1, characterized in that, The specific steps for performing dynamic scheduling include: When the system starts, the AI ​​model is integrated into the SOME / IP middleware as a plug-in to establish a real-time data interaction channel between the model and the middleware. When a new service request arrives, extract the request characteristics and current system status data, and input them into the AI ​​model; The AI ​​model infers and outputs scheduling decisions, which include at least one of the following: service priority adjustment, resource allocation ratio setting, ECU node routing of service requests, and service instance number control. The SOME / IP middleware performs service resource allocation operations based on scheduling decisions.

6. The method for dynamically scheduling SOME / IP service resources using AI according to claim 1, characterized in that, The specific steps to achieve feedback optimization include: Monitor the execution process of scheduling decisions in real time and collect actual response time and system throughput as performance data; Set update trigger conditions, wherein the conditions are for processing a preset number of service requests or every preset time interval; When the triggering conditions are met, performance data is input into the AI ​​model, and online learning algorithms are used to fine-tune the model parameters. Verify the scheduling performance of the fine-tuned model. If the performance meets the requirements, update the model; otherwise, readjust the parameters and verify again.

7. The method for dynamically scheduling SOME / IP service resources using AI according to claim 1, characterized in that, Before integrating the trained AI model into the SOME / IP middleware, a service registration step is also included, which specifically includes: After the system starts up, each SOME / IP service sends a registration request to the SOME / IP middleware; When registering, each service submits a resource requirement profile, which includes the maximum CPU utilization, memory requirements, and expected response latency threshold required for the service to run. The SOME / IP middleware stores the registration information and resource requirement profiles of each service, providing data support for subsequent dynamic scheduling.

8. An apparatus for dynamically scheduling SOME / IP service resources using AI, characterized in that, The device includes: The collection module is used to deploy collection agents on SOME / IP nodes to continuously collect historical service request data and real-time system status data; The training module is used to build a training dataset based on the collected data, define the state space, action space and reward function of the AI ​​scheduling model, and generate an initial scheduling policy through training. The execution module is used to integrate the trained AI model into the SOME / IP middleware. When a service request arrives, the AI ​​model analyzes the real-time service request and system status, outputs scheduling decisions, and executes the allocation of SOME / IP service resources. The feedback module is used to monitor the actual execution performance of scheduling decisions, collect performance data and feed it back to the AI ​​model, and iterate and update the model based on the feedback data to optimize the scheduling strategy.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the AI ​​dynamic scheduling SOME / IP service resource method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the AI ​​dynamic scheduling of SOME / IP service resources as described in any one of claims 1 to 7.

Images