A containerized elastic resource scheduling method and system for a fault diagnosis model

Abstract

A containerized elastic resource scheduling method and system for a fault diagnosis model, which deploys rail transit vehicle fault diagnosis models such as traction systems, braking systems, bogies, door systems, and axle temperature prediction in a lightweight container manner, monitors task queue length, task arrival rate, model reasoning time consumption, CPU occupancy, memory occupancy, GPU occupancy, task waiting time, fault level, and node idle resources in real time, calculates a comprehensive load score, and dynamically executes model container expansion, contraction, resource reservation, and high-priority task scheduling in combination with typical business scenarios such as rail transit vehicle batch return-to-depot maintenance, sudden critical fault, and low-load operation. The present application can solve the problems of insufficient resources during peak periods, waste of resources during low-peak periods, and delayed response to sudden critical fault tasks caused by fixed resource allocation, and improve the real-time performance, reliability, and resource utilization of the rail transit vehicle fault diagnosis system.

Description

Technical Field

[0001] This invention belongs to the technical fields of intelligent operation and maintenance, fault diagnosis, PHM health management, cloud computing resource scheduling and containerized deployment of rail transit vehicles, and specifically relates to a containerized elastic resource scheduling method and system for a fault diagnosis model. Background Technology

[0002] With the continuous expansion of my country's high-speed railway, intercity railway, and urban rail transit networks and the sustained increase in train operation density, the role of vehicle condition monitoring, fault diagnosis, and predictive maintenance systems in ensuring rail transit safety is becoming increasingly prominent. During long-term operation, key components of rail transit vehicles, such as traction systems, braking systems, bogies, door systems, air conditioning systems, wheelset axle boxes, pantographs, motors, and gearboxes, are affected by factors such as fatigue, wear, impact, temperature rise, vibration, and electrical aging, leading to performance degradation or potential faults. To promptly detect abnormal vehicle conditions, the rail transit industry has gradually established intelligent fault diagnosis systems based on vehicle operation data, maintenance data, sensor data, image data, and fault log data.

[0003] Existing rail transit vehicle fault diagnosis systems typically employ a centralized or semi-centralized deployment approach. This involves uploading multi-source data collected from the vehicle, such as vibration, temperature, current, voltage, pressure, images, and logs, to a central server or edge computing nodes, and then calling relevant diagnostic models for analysis. With the development of deep learning, machine learning, and expert rule models, rail transit fault diagnosis systems often deploy multiple diagnostic models, such as bogie vibration anomaly identification models, traction motor temperature rise anomaly diagnosis models, braking system pressure anomaly judgment models, door opening and closing anomaly diagnosis models, axle temperature anomaly prediction models, and image defect recognition models.

[0004] However, in actual rail transit operation and maintenance scenarios, fault diagnosis tasks exhibit significant spatiotemporal fluctuations and sudden business disruptions. First, during peak vehicle return to depots, centralized maintenance, or nighttime batch operations, a large amount of vehicle status data, maintenance records, fault logs, and sensor data are uploaded simultaneously, causing a rapid increase in the length of the diagnostic task queue and placing instantaneous high-concurrency pressure on the model inference service. Second, when critical systems such as traction, braking, doors, and running gear experience abnormal alarms during vehicle operation, multiple models need to be immediately invoked for joint diagnosis to quickly determine the fault level and provide handling recommendations; these tasks have high priority and strong real-time requirements. Third, during stable daytime operation or off-peak periods, the volume of diagnostic tasks decreases significantly. Maintaining a fixed amount of computing resources would result in long-term idle CPU, GPU, memory, and storage resources, increasing system construction costs and energy consumption.

[0005] Existing resource allocation methods typically have the following shortcomings: 1. Fixed resource allocation leads to waste or insufficiency. Traditional systems often pre-configure fixed CPU, memory, or GPU resources for diagnostic models. During peak periods, insufficient resources increase task queuing times; during off-peak periods, resources are idle, resulting in wasted computing resources. 2. General elastic scaling strategies lack the characteristics of rail transit business. Existing container platforms such as Kubernetes can perform elastic scaling based on CPU or memory utilization, but they are mainly geared towards general Internet services and are difficult to reflect the business priority, fault level, vehicle operating status and maintenance scenario of rail transit fault diagnosis tasks. 3. Sudden fault tasks are easily blocked by ordinary tasks. When there are a large number of batch diagnostic tasks in the system, sudden high-priority fault tasks may be occupied by the ordinary task queue, resulting in delays in critical fault diagnosis and affecting driving safety. 4. The model deployment and resource scheduling are highly coupled. Existing diagnostic models are often deployed on fixed servers or fixed service instances. The model expansion, migration and version update are not flexible enough and it is difficult to adapt to the dynamic deployment requirements of different routes, different vehicle types and different diagnostic models.

[0006] Therefore, there is an urgent need for a containerized elastic resource scheduling method that combines the characteristics of rail transit vehicle fault diagnosis services, so that diagnostic model resources can be dynamically adjusted according to task load, fault level, vehicle operation scenario and node resource status, thereby improving the utilization rate of computing resources while ensuring the real-time performance of critical fault diagnosis. Summary of the Invention

[0007] To overcome the problems of wasted computing resources due to fixed resource allocation, delayed processing of diagnostic tasks during peak periods, untimely response to sudden fault tasks, and the difficulty of adapting general container scaling strategies to rail transit business scenarios in existing technologies, this invention proposes a containerized elastic resource scheduling method and system for rail transit vehicle fault diagnosis models.

[0008] This method relies on lightweight container technology to deploy rail transit vehicle fault diagnosis models in a containerized manner. It combines indicators such as task load, task queue length, CPU utilization, memory utilization, model inference latency, task waiting time, fault level, and vehicle operation scenario to construct dynamic resource allocation strategies for batch diagnosis scenarios, sudden fault scenarios, and low load scenarios. This enables automatic expansion and contraction of diagnostic model container copies, priority scheduling, and idle node invocation.

[0009] To achieve the above objectives, this invention provides a containerized elastic resource scheduling method for a fault diagnosis model, comprising the following steps: Step S1: Collect information on rail transit vehicle fault diagnosis tasks, model container operating status, and computing node resource information; Step S2: Classify fault diagnosis tasks according to task source, task type, vehicle operating status, fault level, and task waiting time, and determine task priority; Step S3: Calculate the comprehensive load score of the model service based on the task queue length, task arrival rate, CPU utilization, memory utilization, GPU utilization, and node idle resources, and use the model inference time as a monitoring indicator of task processing effect. Step S4: Based on the comprehensive load score and task priority, determine whether the current diagnostic scenario belongs to a high-load batch diagnostic scenario, a sudden fault diagnostic scenario, a normal stable scenario, or a low-load idle scenario. Step S5: In high-load batch diagnostic scenarios, automatically increase the number of container replicas of the corresponding fault diagnosis model and call idle computing nodes to execute batch diagnostic tasks; Step S6: In the case of sudden fault diagnosis, reserve computing resources for high-priority diagnosis tasks, adjust the task execution order, or trigger rapid expansion according to the fault level; Step S7: Under normal and stable scenarios, maintain the current number of model container replicas and resource quotas, allocate diagnostic tasks to currently available model container replicas for execution according to the predetermined task priority, and continuously monitor the task queue status, model container running status, and computing node resource information. Step S8: In low-load idle scenarios, automatically reduce the number of model container replicas and release redundant computing node resources.

[0010] Furthermore, in step S1, the fault diagnosis task information includes vehicle number, route number, task source, task type, task submission time, task data volume, required diagnostic model type, fault level, task waiting time, and task deadline; the model container running status information and computing node resource information include CPU utilization, memory utilization, GPU utilization, number of model container replicas, average inference time per task, current task queue length, task arrival rate, average task waiting time, node idle resources, and container startup time; wherein, the node idle resources include CPU, memory, GPU, and network resources.

[0011] Furthermore, in step S2, the formula is used. Calculate the task priority score P; where F is the fault severity, S is the vehicle operating status weight, T is the task waiting time weight, and R is the task real-time requirement weight. , , , The weight coefficients are configurable. If P exceeds the preset threshold, it is determined to be a high-priority task. F, S, T and R are converted into dimensionless values ​​from 0 to 1 through a preset level table or normalization function. a1 to a4 are non-negative configurable weight coefficients and their sum is 1. The task is mapped to the fourth priority level according to the preset scoring interval where P is located.

[0012] Furthermore, in step S2, the task priority is divided into four levels: Level 1 is safety-critical fault tasks, Level 2 is fault tasks affecting operational efficiency, Level 3 is planned maintenance tasks, and Level 4 is historical data analysis tasks.

[0013] Furthermore, the safety-critical fault tasks include tasks related to brake system malfunctions, serious traction system alarms, abnormal axle temperature rise, abnormal vibration of the running gear, and risk of people being trapped in the doors; the fault tasks affecting operational efficiency include tasks related to air conditioning system malfunctions, abnormal door opening and closing times, and abnormal auxiliary power supply.

[0014] Furthermore, in step S3, the formula is used. Calculate the overall load score L; where To normalize the task queue length, For CPU utilization, For memory utilization, Here, W represents GPU utilization, R represents the average task wait time, R represents the task arrival rate, and N represents the available idle node resources. Here, are the weighting coefficients; The result is obtained by dividing the current task queue length by the preset reference queue length and limiting the result to the range of 0 to 1. W and R are the average waiting time and task arrival rate of the task normalized by the preset baseline value, respectively, and N is the normalized amount of idle resources calculated based on the available CPU, memory, GPU and network resources of the node.

[0015] Furthermore, step S3 sets three levels of judgment thresholds: when L is greater than the first threshold L1, the system enters the expansion candidate state; when L is greater than the second threshold L2 and continues to exceed the set time window, the system performs expansion; when L is lower than the third threshold L3 and there are no high-priority tasks, the system performs shrinkage.

[0016] Furthermore, in step S4, the criteria for determining high-load scenarios in batch diagnosis are that the three indicators of task queue length, task arrival rate, and average task waiting time all exceed their respective preset thresholds, and there are no first-level safety critical fault tasks that need to be processed immediately.

[0017] Furthermore, step S5 specifically includes: screening schedulable nodes that have sufficient CPU, memory, GPU, and network resources to meet the requirements of the model container to be expanded; selecting the target node and generating expansion instructions, adding corresponding model container replicas according to the model type, and allocating batch tasks to the newly added replicas for parallel execution; if there are no available nodes, recording the resource shortage status and waiting or issuing an alarm.

[0018] Furthermore, step S6 specifically includes the following steps: for high-priority fault tasks, first query the currently available model container replicas; if an idle replica exists, immediately allocate and execute it; if no idle replica exists, check if any low-priority tasks are occupying resources; if it can be paused or postponed, pause or postpone the low-priority tasks and release resources; otherwise, the elastic scaling control module triggers rapid expansion, starts emergency container replicas and reserves CPU, GPU and memory resources, then performs high-priority fault diagnosis and outputs results first; rapid expansion is not constrained by the comprehensive load score threshold.

[0019] Furthermore, step S7 also includes: when the overall load score reaches the expansion candidate threshold, a high-priority fault diagnosis task occurs, or the overall load score is continuously lower than the reduction threshold, the system switches to batch diagnosis of high-load scenario, sudden fault diagnosis scenario, and low-load idle scenario, respectively.

[0020] Furthermore, step S8 specifically includes the following: when the task queue length, CPU utilization, memory utilization, and GPU utilization are lower than preset thresholds within multiple consecutive time windows, and there are no high-priority tasks, the system performs scaling down.

[0021] Furthermore, step S8 specifically includes: when the low load continues for more than a time window, calculating the number of model container replicas that can be reduced; if the number of reduced replicas is lower than the minimum number of service replicas, then retaining the minimum number of service replicas and continuing to monitor; otherwise, sending a reduction command to the container orchestration platform to stop redundant model container replicas, releasing CPU, GPU and memory resources and reclaiming idle nodes to the resource pool, while recording the reduction result and entering a cooling-off period.

[0022] Furthermore, the method also includes step S9: calculating the average waiting time of the task, the model inference time, the task completion rate, and the resource utilization rate according to a preset feedback cycle; when the average waiting time of the task or the model inference time exceeds the target value, reducing the expansion threshold or increasing the number of expansion replicas within a preset adjustment range; when the resource utilization rate is lower than the target value and there are no high-priority tasks, increasing the expansion threshold or decreasing the number of expansion replicas within a preset adjustment range, and using the adjusted parameters for subsequent resource scheduling.

[0023] This invention also provides a containerized elastic resource scheduling system for a fault diagnosis model, comprising: The data access module is used to receive vehicle operation data, trackside inspection data, maintenance data and fault log data, and to perform format verification and standardization processing on the data to be diagnosed and task information. The task queue module is used to generate, cache, and manage the fault diagnosis task queue; The task priority scheduling module is used to determine the priority of diagnostic tasks based on fault level, vehicle operating status, task waiting time and business rules, and to perform queue rearrangement and task allocation. The model container management module is used to encapsulate fault diagnosis models and their runtime dependencies into container images, and manage the creation, startup, shutdown, scaling up and down, and health status of model container replicas through the container orchestration platform. The resource monitoring module is used to monitor the CPU utilization, memory utilization, GPU utilization, running status, and idle resources of model containers through the container orchestration platform interface, node monitoring agent, and container runtime interface. The load scoring module is used to calculate the overall load score of the fault diagnosis model service; The business scenario identification module is used to identify high-load batch diagnostic scenarios, sudden fault diagnostic scenarios, normal stable scenarios, and low-load idle scenarios. The elastic scaling control module is used to generate instructions for scaling up and down the model container replica, preheating resources, and releasing resources based on the business scenario identification results. The diagnostic results output module is used to output fault diagnosis results, fault level, maintenance suggestions and early warning information.

[0024] Compared with existing technologies, this invention calculates a comprehensive load score for the fault diagnosis model service by collecting data on task queue length, task arrival rate, CPU utilization, memory utilization, GPU utilization, and node idle resources. It then determines task priorities by combining fault severity, vehicle operating status, task waiting time, and task real-time requirements, thereby identifying high-load, sudden fault diagnosis, normal stable, and low-load idle scenarios for batch diagnosis. In high-load batch diagnosis scenarios, by selecting schedulable nodes that meet resource requirements and adding corresponding model container replicas, batch tasks are allocated to the newly added replicas for parallel execution, which improves the processing capacity of batch diagnosis tasks and reduces task queuing time. In sudden fault diagnosis scenarios, by prioritizing the scheduling of high-priority fault tasks, delaying low-priority tasks, and triggering rapid expansion, it helps reduce the blocking of safety-critical fault tasks by ordinary tasks. In low-load idle scenarios, by retaining the minimum service replica and releasing redundant container and node resources, it helps reduce idle computing resources. In addition, by adding container health checks, expansion and contraction time windows, cooling mechanisms, and feedback corrections based on task processing results, the stability of model container resource scheduling can be improved, and the resource scheduling fluctuations caused by frequent expansion and contraction can be reduced, thereby improving the real-time performance, resource utilization, and operational reliability of the rail transit vehicle fault diagnosis system. Attached Figure Description

[0025] Figure 1 This is an overall flowchart of the method of the present invention; Figure 2 This is a system structure diagram of the present invention; Figure 3 This is a resource scheduling strategy diagram for the present invention; Figure 4 This is a flowchart of the batch diagnostic expansion process of the present invention; Figure 5 This is a flowchart of the emergency fault priority scheduling process of the present invention; Figure 6 This is a flowchart of the low-load scaling-up process of the present invention. Detailed Implementation

[0026] This invention provides a containerized elastic resource scheduling method for a fault diagnosis model, comprising the following steps: Step S1: Collect information on rail transit vehicle fault diagnosis tasks, model container operating status, and computing node resource information; Step S2: Classify fault diagnosis tasks according to task source, task type, vehicle operating status, fault level, and task waiting time, and determine task priority; Step S3: Calculate the comprehensive load score of the model service based on the task queue length, task arrival rate, CPU utilization, memory utilization, GPU utilization, and node idle resources, and use the model inference time as a monitoring indicator of task processing effect. Step S4: Based on the comprehensive load score and task priority, determine whether the current diagnostic scenario belongs to a high-load batch diagnostic scenario, a sudden fault diagnostic scenario, a normal stable scenario, or a low-load idle scenario. Step S5: In high-load batch diagnostic scenarios, automatically increase the number of container replicas of the corresponding fault diagnosis model and call idle computing nodes to execute batch diagnostic tasks; Step S6: In the case of sudden fault diagnosis, reserve computing resources for high-priority diagnosis tasks, adjust the task execution order, or trigger rapid expansion according to the fault level; Step S7: Under normal and stable scenarios, maintain the current number of model container replicas and resource quotas, allocate diagnostic tasks to currently available model container replicas for execution according to the predetermined task priority, and continuously monitor the task queue status, model container running status, and computing node resource information. Step S8: In low-load idle scenarios, automatically reduce the number of model container replicas and release redundant computing node resources.

[0027] Furthermore, in step S1, the fault diagnosis task information includes vehicle number, route number, task source, task type, task submission time, task data volume, required diagnostic model type, fault level, task waiting time, and task deadline; the model container running status information and computing node resource information include CPU utilization, memory utilization, GPU utilization, number of model container replicas, average inference time per task, current task queue length, task arrival rate, average task waiting time, node idle resources, and container startup time; wherein, the node idle resources include CPU, memory, GPU, and network resources.

[0028] Furthermore, in step S2, the formula is used. Calculate the task priority score P; where F is the fault severity, S is the vehicle operating status weight, T is the task waiting time weight, and R is the task real-time requirement weight. , , , The weight coefficients are configurable. If P exceeds the preset threshold, it is determined to be a high-priority task. F, S, T and R are converted into dimensionless values ​​from 0 to 1 through a preset level table or normalization function. a1 to a4 are non-negative configurable weight coefficients and their sum is 1. The task is mapped to the fourth priority level according to the preset scoring interval where P is located.

[0029] Furthermore, in step S2, the task priority is divided into four levels: Level 1 is safety-critical fault tasks, Level 2 is fault tasks affecting operational efficiency, Level 3 is planned maintenance tasks, and Level 4 is historical data analysis tasks.

[0030] Furthermore, the safety-critical fault tasks include tasks related to brake system malfunctions, serious traction system alarms, abnormal axle temperature rise, abnormal vibration of the running gear, and risk of people being trapped in the doors; the fault tasks affecting operational efficiency include tasks related to air conditioning system malfunctions, abnormal door opening and closing times, and abnormal auxiliary power supply.

[0031] Furthermore, in step S3, the formula is used. Calculate the overall load score L; where To normalize the task queue length, For CPU utilization, For memory utilization, Here, W represents GPU utilization, R represents the average task wait time, R represents the task arrival rate, and N represents the available idle node resources. Here, are the weighting coefficients; The result is obtained by dividing the current task queue length by the preset reference queue length and limiting the result to the range of 0 to 1. W and R are the average waiting time and task arrival rate of the task normalized by the preset baseline value, respectively, and N is the normalized amount of idle resources calculated based on the available CPU, memory, GPU and network resources of the node.

[0032] Furthermore, step S3 sets three levels of judgment thresholds: when L is greater than the first threshold L1, the system enters the expansion candidate state; when L is greater than the second threshold L2 and continues to exceed the set time window, the system performs expansion; when L is lower than the third threshold L3 and there are no high-priority tasks, the system performs shrinkage.

[0033] Furthermore, in step S4, the criteria for determining high-load scenarios in batch diagnosis are that the three indicators of task queue length, task arrival rate, and average task waiting time all exceed their respective preset thresholds, and there are no first-level safety critical fault tasks that need to be processed immediately.

[0034] Furthermore, step S5 specifically includes: screening schedulable nodes that have sufficient CPU, memory, GPU, and network resources to meet the requirements of the model container to be expanded; selecting the target node and generating expansion instructions, adding corresponding model container replicas according to the model type, and allocating batch tasks to the newly added replicas for parallel execution; if there are no available nodes, recording the resource shortage status and waiting or issuing an alarm.

[0035] Furthermore, step S6 specifically includes the following steps: for high-priority fault tasks, first query the currently available model container replicas; if an idle replica exists, immediately allocate and execute it; if no idle replica exists, check if any low-priority tasks are occupying resources; if it can be paused or postponed, pause or postpone the low-priority tasks and release resources; otherwise, the elastic scaling control module triggers rapid expansion, starts emergency container replicas and reserves CPU, GPU and memory resources, then performs high-priority fault diagnosis and outputs results first; rapid expansion is not constrained by the comprehensive load score threshold.

[0036] Furthermore, step S7 also includes: when the overall load score reaches the expansion candidate threshold, a high-priority fault diagnosis task occurs, or the overall load score is continuously lower than the reduction threshold, the system switches to batch diagnosis of high-load scenario, sudden fault diagnosis scenario, and low-load idle scenario, respectively.

[0037] Furthermore, step S8 specifically includes the following: when the task queue length, CPU utilization, memory utilization, and GPU utilization are lower than preset thresholds within multiple consecutive time windows, and there are no high-priority tasks, the system performs scaling down.

[0038] Furthermore, step S8 specifically includes: when the low load continues for more than a time window, calculating the number of model container replicas that can be reduced; if the number of reduced replicas is lower than the minimum number of service replicas, then retaining the minimum number of service replicas and continuing to monitor; otherwise, sending a reduction command to the container orchestration platform to stop redundant model container replicas, releasing CPU, GPU and memory resources and reclaiming idle nodes to the resource pool, while recording the reduction result and entering a cooling-off period.

[0039] Furthermore, the method also includes step S9: calculating the average waiting time of the task, the model inference time, the task completion rate, and the resource utilization rate according to a preset feedback cycle; when the average waiting time of the task or the model inference time exceeds the target value, reducing the expansion threshold or increasing the number of expansion replicas within a preset adjustment range; when the resource utilization rate is lower than the target value and there are no high-priority tasks, increasing the expansion threshold or decreasing the number of expansion replicas within a preset adjustment range, and using the adjusted parameters for subsequent resource scheduling.

[0040] This invention also provides a containerized elastic resource scheduling system for a fault diagnosis model, comprising: The data access module is used to receive vehicle operation data, trackside inspection data, maintenance data and fault log data, and to perform format verification and standardization processing on the data to be diagnosed and task information. The task queue module is used to generate, cache, and manage the fault diagnosis task queue; The task priority scheduling module is used to determine the priority of diagnostic tasks based on fault level, vehicle operating status, task waiting time and business rules, and to perform queue rearrangement and task allocation. The model container management module is used to encapsulate fault diagnosis models and their runtime dependencies into container images, and manage the creation, startup, shutdown, scaling up and down, and health status of model container replicas through the container orchestration platform. The resource monitoring module is used to monitor the CPU utilization, memory utilization, GPU utilization, running status, and idle resources of model containers through the container orchestration platform interface, node monitoring agent, and container runtime interface. The load scoring module is used to calculate the overall load score of the fault diagnosis model service; The business scenario identification module is used to identify high-load batch diagnostic scenarios, sudden fault diagnostic scenarios, normal stable scenarios, and low-load idle scenarios. The elastic scaling control module is used to generate instructions for scaling up and down the model container replica, preheating resources, and releasing resources based on the business scenario identification results. The diagnostic results output module is used to output fault diagnosis results, fault level, maintenance suggestions and early warning information.

[0041] The invention will now be further described with reference to the accompanying drawings.

[0042] like Figure 1 As shown, the overall process of this invention is as follows: The data access module receives vehicle operation data, maintenance data, sensor data, and fault logs, forms diagnostic tasks, and writes them to the task queue module; the task priority scheduling module completes task classification and priority determination; the resource monitoring module collects the status of model containers and computing nodes; the load scoring module calculates the comprehensive load score; and the business scenario identification module identifies the business scenario accordingly. For high-load batch diagnostic scenarios, the elastic scaling control module issues an expansion command, and the model container management module adds replicas; for sudden fault diagnosis scenarios, the task priority scheduling module implements resource reservation, task queueing, or triggers rapid expansion; for normal stable scenarios, the current number of model container replicas and task priority scheduling strategy are maintained, and no expansion, contraction, or task preemption operations are performed, while continuous resource monitoring is conducted; for low-load idle scenarios, the elastic scaling control module implements contraction and releases resources.

[0043] As a specific embodiment, the system described in this invention is deployed in an intelligent operation and maintenance platform for rail transit vehicles, and can be deployed in a central data center, a depot edge computing center, or a line-level cloud platform. The term "system" as used hereafter refers to the containerized elastic resource scheduling system of this invention. The system uses containerization technology to encapsulate different fault diagnosis models. The model container management module encapsulates the fault diagnosis model, model runtime environment, and inference dependencies into container images. A model container is a container instance created based on the container image, which can be independently deployed, run, and managed. The same fault diagnosis model can correspond to multiple model container copies. The model container management module calls the container orchestration platform to complete the creation, startup, shutdown, scaling, and health status management of container copies.

[0044] The fault diagnosis model includes, but is not limited to: Traction system fault diagnosis model; Braking system fault diagnosis model; Bogie vibration abnormality diagnosis model; Door opening and closing abnormality diagnosis model; Axle temperature abnormality prediction model; Pantograph status identification model; Air conditioning system abnormality diagnosis model; Wheelset wear status assessment model; Vehicle comprehensive health assessment model.

[0045] The system comprises a data access module, a task queue module, a model container management module, a resource monitoring module, a load scoring module, a business scenario identification module, an elastic scaling control module, a task priority scheduling module, and a diagnostic result output module. Specifically, the data access module receives and standardizes task data; the task queue module caches tasks awaiting processing; the resource monitoring module acquires resources and their operational status through container orchestration platform interfaces, node monitoring agents, and container runtime interfaces; the load scoring module calculates a comprehensive load score; the business scenario identification module identifies scheduling scenarios; the elastic scaling control module generates scaling, resource preheating, and resource release commands; the task priority scheduling module performs task classification, priority calculation, queue rearrangement, and task allocation; and the diagnostic result output module outputs diagnostic conclusions, fault levels, maintenance suggestions, and early warning information.

[0046] like Figure 2 As shown, the onboard sensors, trackside detection equipment, maintenance system, and fault logs in the data acquisition layer provide data to the data access module; the data access module, together with the task queue module, task priority scheduling module, load scoring module, and business scenario identification module, constitute the task scheduling layer; the model container management module, resource monitoring module, and elastic scaling control module are deployed in the container orchestration layer and interact with the Kubernetes cluster; the traction system diagnostic model, braking system diagnostic model, door system diagnostic model, and bogie diagnostic model constitute the model service layer in the form of model container copies; the diagnostic result output module forms a diagnostic result layer including fault level, diagnostic conclusion, maintenance suggestions, and early warning information.

[0047] As a specific embodiment two: The data access module receives diagnostic data and task information from the onboard PHM system, trackside inspection equipment, depot maintenance system, manual verification system, or central monitoring system. After format verification and standardization, the data is written to the task queue module. The task information includes: Task source; vehicle number; route number; vehicle operating status; task type; task submission time; task data volume; required model type; task fault level; task waiting time; task deadline.

[0048] The sources of tasks can be onboard PHM systems, trackside inspection equipment, depot maintenance systems, manual verification systems, or central monitoring systems. Task types can include real-time alarm diagnosis tasks, batch return-to-depot diagnosis tasks, planned maintenance analysis tasks, historical data review tasks, and health trend prediction tasks.

[0049] As a specific embodiment three: The task priority scheduling module sets task priorities according to the rail transit business rules, and rearranges the task queue and assigns tasks based on the priorities.

[0050] Priority can be divided into four levels: Level 1, Level 2, Level 3, and Level 4. Level 1 tasks are safety-critical fault tasks, such as brake system malfunctions, serious traction system alarms, abnormal axle temperature rise, abnormal vibration of the running gear, and risk of people being trapped in the doors. Level 2 tasks are fault tasks that affect operational efficiency, such as air conditioning malfunctions, abnormal door opening and closing times, and auxiliary power supply malfunctions. Level 3 tasks are planned maintenance tasks, such as batch condition assessment after returning to the warehouse and component life prediction. Level 4 tasks are historical data analysis tasks, such as offline model review, statistical analysis, and report generation.

[0051] Task priority can be calculated in the following way: Where P represents the task priority score, F represents the fault severity, S represents the vehicle operating status weight, T represents the task waiting time weight, R represents the task real-time requirement weight, and a1, a2, a3, and a4 are configurable weight coefficients.

[0052] When P exceeds a preset threshold, the task is classified as a high-priority task.

[0053] The corresponding range of priority score P and the fourth priority level, the thresholds of various tasks, and the weight coefficients are all preset by the business configuration table, and can be configured separately according to route, vehicle type, or time period; the configuration table at least saves the upper and lower limits of each score range and the high priority judgment threshold.

[0054] As a specific embodiment four: the resource monitoring module periodically collects the running status of the model containers and the resource information of the computing nodes they reside on through the container orchestration platform interface, node monitoring agent, and container runtime interface, including: CPU utilization; memory utilization; GPU utilization; number of model container replicas; average inference time per task; current task queue length; task arrival rate; average task waiting time; node idle resources; container startup time; where the number of model container replicas refers to the number of model container instances running the same fault diagnosis model simultaneously, used to characterize the parallel inference capability of the model service.

[0055] The overall load score L can be expressed in the following form: in, Indicates the normalized task queue length. Indicates CPU utilization. Indicates memory utilization. W represents GPU utilization, R represents average task wait time, N represents available idle node resources, and b1 to b7 are weighting coefficients.

[0056] When L is greater than the first threshold L1, the system enters the expansion candidate state; when L is greater than the second threshold L2 and the duration exceeds the first set time window, the system performs expansion; when L is lower than the third threshold L3, the duration exceeds the second set time window and there are no high-priority tasks, the system performs shrinkage; where L3 < L1 < L2, after expansion or shrinkage is completed, a cooling timer is started, and expansion or shrinkage commands in the same direction are not sent repeatedly for the same model service during the cooling time.

[0057] like Figure 3 As shown, the resource monitoring module inputs the task queue length Q, CPU / memory / GPU utilization, average task waiting time W, task arrival rate R, fault priority P, and node idle resources N into the load scoring module to obtain a comprehensive load score L. The business scenario identification module determines that it is a batch expansion when L is high and Q is long, that it is a priority guarantee when P is high, that it is a shrinkage release when L is low and there are no high-priority tasks, and that it is normal and stable and maintains the current resource configuration in other cases.

[0058] As a specific embodiment five: When the overall load score L is within the preset stable range L3≤L<L1, the task queue length and average task waiting time do not exceed the corresponding thresholds, the CPU, memory, and GPU resource utilization of the model container and computing nodes are within the normal range, and the task priority scheduling module does not detect any high-priority tasks requiring resource reservation, the business scenario identification module determines that the system has entered a normal stable scenario. The processing flow of the normal stable scenario includes: the resource monitoring module continuously collects the running status of the model container, the idle resources of the nodes, and the status of the task queue according to a preset cycle; the load scoring module continuously updates the overall load score L; the task priority scheduling module selects tasks from the task queue according to a predetermined priority and assigns them to currently available model container replicas for execution; the elastic scaling control module maintains the current number of model container replicas and resource quotas, and does not send expansion, reduction, or task preemption commands; the diagnostic result output module outputs diagnostic conclusions, fault levels, maintenance suggestions, and early warning information. When it is detected that L reaches the expansion candidate threshold, a high-priority fault diagnosis task appears, or L is continuously lower than the reduction threshold, the business scenario identification module exits the normal stable scenario and switches to the batch diagnosis high-load scenario, the sudden fault diagnosis scenario, or the low-load idle scenario, respectively.

[0059] As a specific embodiment six: When vehicles are returned to the depot in a concentrated manner, undergo centralized maintenance, and data is uploaded in batches, the system will generate a large number of diagnostic tasks with low real-time requirements. If a fixed number of model container replicas is still used at this time, that is, a pre-configured number of model container replicas that is not dynamically adjusted with the task load, it will lead to excessively long task queuing times and affect maintenance efficiency.

[0060] This invention designs a batch diagnostic and capacity expansion strategy for this scenario: The resource monitoring module monitors the task queue length Q, task arrival rate R, and average task waiting time W. When Q, R, and W all exceed the threshold, the business scenario identification module determines that the system has entered a high-load scenario for batch diagnosis. The resource monitoring module queries the current cluster for idle nodes, which are schedulable nodes with the CPU, memory, GPU, and network resources required to expand the model container. The elastic scaling control module selects the target node and generates expansion instructions. The model container management module adds corresponding model container replicas according to the model type. The task priority scheduling module allocates batch tasks to the newly added replicas for parallel execution. As the task backlog decreases, the elastic scaling control module gradually scales down.

[0061] This strategy can improve diagnostic throughput during peak maintenance periods and reduce vehicle waiting time for maintenance.

[0062] like Figure 4As shown, in the batch diagnostic expansion process, the resource monitoring module sequentially obtains Q, R, W, and the current model container resource utilization rate; the business scenario identification module determines whether the batch high load conditions are met. If met, the resource monitoring module queries the cluster for idle computing nodes; if available nodes exist, the elastic scaling control module calculates the required number of expansion replicas, the model container management module sends expansion instructions to the container orchestration platform and starts the new model container, and the task priority scheduling module allocates the batch diagnostic tasks to the new container for parallel execution; if no available nodes exist, the resource insufficiency status is recorded and a waiting or alarm is triggered; if the conditions are not met, the current number of replicas is maintained and monitoring continues.

[0063] The expansion instruction includes at least the target model identifier, the number of target replicas, and the CPU, memory, GPU, and network resource requests and limits for each replica. After a new model container is started, the model container management module confirms its availability based on the health check results. Only newly added replicas that are in an available state receive diagnostic tasks. If a new replica does not enter an available state within the preset startup waiting time, the startup failure is recorded and the corresponding task allocation is revoked or a new node is selected.

[0064] As a specific embodiment seven: During rail transit operation, if a vehicle experiences malfunctions such as abnormal braking, abnormal traction, abnormal axle temperature, strong vibration in the running gear, or abnormal doors, rapid diagnosis and result output are required. If the system is processing a large number of batch tasks at this time, sudden tasks may be blocked.

[0065] This invention designs a high-priority task protection strategy for this situation: identify the task failure level; determine whether the task is a safety-critical failure; if it is a high-priority task, enter the priority scheduling process; suspend some low-priority tasks; allocate available container replicas to high-priority tasks; if there are no available replicas, trigger rapid expansion; set resource reservations for high-priority tasks; and prioritize the output of diagnostic results and handling suggestions.

[0066] This strategy can prevent critical fault tasks from being blocked by ordinary tasks, thereby improving the safety assurance capability of rail transit operations.

[0067] like Figure 5As shown, in the emergency fault priority scheduling process, the task priority scheduling module receives real-time fault alarm tasks, parses the vehicle number, component type, and fault type, and calculates the fault severity and task priority P. For high-priority fault tasks, it first queries the currently available model container replicas; if an idle replica exists, it immediately assigns the task for execution; if no idle replica exists, it checks if any low-priority tasks are occupying resources. If it can be paused or postponed, the low-priority task is paused or postponed and resources are released; otherwise, the elastic scaling control module triggers rapid expansion, the model container management module starts an emergency container replica for the corresponding model and reserves CPU, GPU, and memory resources, and then executes high-priority fault diagnosis and outputs the results first.

[0068] For low-priority tasks that have not yet started execution, queue insertion is achieved through task queue rearrangement and delayed allocation; for low-priority tasks that have already started inference, model inference is not forcibly terminated, but resources are released after the current inference is completed to avoid the loss of intermediate results; emergency container replicas reserve resources through resource requests, resource limits and scheduling constraints of the container orchestration platform.

[0069] As a specific embodiment eight: Maintaining a large number of model container copies during non-maintenance periods, off-peak hours, or when workloads are low will waste computing resources. This invention designs a low-load scaling-down strategy: Monitor task queue length; monitor CPU, memory, and GPU utilization; determine if there are high-priority tasks; if the load is below the threshold for multiple consecutive time windows, reduce model container replicas; retain the minimum number of service replicas; release idle nodes to the resource pool; and shut down some edge nodes or reduce resource usage if necessary.

[0070] This strategy can reduce system operating costs and improve the utilization of computing resources.

[0071] like Figure 6 As shown, in the low-load scaling-down process, the resource monitoring module periodically acquires Q, CPU / memory / GPU utilization, and the status of high-priority tasks; the business scenario identification module enters the duration window judgment after the low-load condition is met. When the low load continues for more than the time window, the elastic scaling control module calculates the number of model container replicas that can be reduced; if the number after scaling down is less than the minimum service replica number, the minimum service replica is retained and monitoring continues; otherwise, the model container management module sends a scaling-down command to the container orchestration platform to stop redundant model container replicas, release CPU, GPU, and memory resources, and reclaim idle nodes to the resource pool, while recording the scaling-down result and entering a cooldown period.

[0072] As a specific embodiment nine: To avoid system oscillations caused by frequent expansion and contraction, this invention sets up a scheduling cooldown time and a feedback correction mechanism.

[0073] Specifically, it includes: After expansion is complete, the model container management module returns the startup completion status of the newly added model container replicas to the elastic scaling control module. The elastic scaling control module records the expansion time and starts the expansion cooldown timer. During the cooldown time, only the resource monitoring module continuously collects indicators and does not repeatedly issue expansion commands in the same direction for the same diagnostic model service. Before scaling down, the resource monitoring module reports the task queue length, average task waiting time, CPU utilization, memory utilization, and GPU utilization over multiple consecutive monitoring periods. The load scoring module calculates the comprehensive load score, the business scenario identification module determines whether it is continuously in a low-load idle scenario, and the task priority scheduling module confirms that there are no high-priority tasks that require resource reservation. When the conditions are met, the elastic scaling control module calculates the number of replicas that can be reduced and sends a scaling down command to the model container management module. During threshold correction, the elastic scaling control module summarizes the average task waiting time, model inference time, task completion rate, and resource utilization according to a preset feedback cycle: when the waiting time or inference time exceeds the target value, the expansion threshold is lowered or the target number of replicas is increased within preset upper and lower limits; when the resource utilization is lower than the target value and there are no high-priority tasks, the expansion threshold is raised or the target number of replicas is reduced within preset upper and lower limits; when the indicators are within the target range, the current parameters are maintained. The elastic scaling control module records task load, scenario determination, expansion / contraction times, and scheduling effects according to routes, vehicle segments, and time periods, forming a load pattern record; before vehicles return to the depot in a concentrated manner, a resource preheating instruction is sent to the model container management module in advance according to the load pattern to create a preset number of model container replicas; during off-peak periods, a shrinkage instruction is sent while ensuring the minimum number of service replicas to reduce CPU, GPU, and memory resource consumption.

[0074] Through the collaborative processing of the above-mentioned resource monitoring module, load scoring module, business scenario identification module, elastic scaling control module, model container management module, and task priority scheduling module, the system can gradually form a dynamic resource scheduling strategy that adapts to the operation rules of rail transit.

Claims

1. A containerized elastic resource scheduling method for a fault diagnosis model, characterized in that, Includes the following steps: Step S1: Collect information on rail transit vehicle fault diagnosis tasks, model container operating status, and computing node resource information; Step S2: Classify fault diagnosis tasks according to task source, task type, vehicle operating status, fault level, and task waiting time, and determine task priority; Step S3: Calculate the comprehensive load score of the model service based on the task queue length, task arrival rate, CPU utilization, memory utilization, GPU utilization, and node idle resources, and use the model inference time as a monitoring indicator of task processing effect. Step S4: Based on the comprehensive load score and task priority, determine whether the current diagnostic scenario belongs to a high-load batch diagnostic scenario, a sudden fault diagnostic scenario, a normal stable scenario, or a low-load idle scenario. Step S5: In high-load batch diagnostic scenarios, automatically increase the number of container replicas of the corresponding fault diagnosis model and call idle computing nodes to execute batch diagnostic tasks; Step S6: In the case of sudden fault diagnosis, reserve computing resources for high-priority diagnosis tasks, adjust the task execution order, or trigger rapid expansion according to the fault level; Step S7: Under normal and stable scenarios, maintain the current number of model container replicas and resource quotas, allocate diagnostic tasks to currently available model container replicas for execution according to the predetermined task priority, and continuously monitor the task queue status, model container running status, and computing node resource information. Step S8: In low-load idle scenarios, automatically reduce the number of model container replicas and release redundant computing node resources.

2. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, In step S1, the fault diagnosis task information includes vehicle number, route number, task source, task type, task submission time, task data volume, required diagnostic model type, fault level, task waiting time, and task deadline; the model container running status information and computing node resource information include CPU utilization, memory utilization, GPU utilization, number of model container replicas, average inference time per task, current task queue length, task arrival rate, average task waiting time, node idle resources, and container startup time; wherein, the node idle resources include CPU, memory, GPU, and network resources.

3. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, In step S2, the formula is used. Calculate the task priority score P; where F is the fault severity, S is the vehicle operating status weight, T is the task waiting time weight, and R is the task real-time requirement weight. , , , The weight coefficients are configurable. If P exceeds the preset threshold, it is determined to be a high-priority task. F, S, T and R are converted into dimensionless values ​​from 0 to 1 through a preset level table or normalization function. a1 to a4 are non-negative configurable weight coefficients and their sum is 1. The task is mapped to the fourth priority level according to the preset scoring interval where P is located.

4. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 3, characterized in that, In step S2, the task priority is divided into four levels: Level 1 is safety-critical fault tasks, Level 2 is fault tasks that affect operational efficiency, Level 3 is planned maintenance tasks, and Level 4 is historical data analysis tasks.

5. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 4, characterized in that, The safety-critical fault tasks include tasks related to brake system malfunctions, serious traction system alarms, abnormal axle temperature rise, abnormal vibration of the running gear, and risk of people being trapped in the doors; the fault tasks affecting operational efficiency include tasks related to air conditioning system malfunctions, abnormal door opening and closing times, and abnormal auxiliary power supply.

6. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, In step S3, the formula is used. Calculate the overall load score L; where To normalize the task queue length, For CPU utilization, For memory utilization, Here, W represents GPU utilization, R represents the average task wait time, R represents the task arrival rate, and N represents the available idle node resources. Here, are the weighting coefficients; The result is obtained by dividing the current task queue length by the preset reference queue length and limiting the result to the range of 0 to 1. W and R are the average waiting time and task arrival rate of the task normalized by the preset baseline value, respectively, and N is the normalized amount of idle resources calculated based on the available CPU, memory, GPU and network resources of the node.

7. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 6, characterized in that, Step S3 sets three levels of judgment thresholds: when L is greater than the first threshold L1, the system enters the expansion candidate state; when L is greater than the second threshold L2 and continues to exceed the set time window, the system performs expansion; when L is lower than the third threshold L3 and there are no high-priority tasks, the system performs shrinkage.

8. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, In step S4, the criteria for batch diagnosis of high-load scenarios are that the three indicators of task queue length, task arrival rate, and average task waiting time all exceed their respective preset thresholds, and there are no first-level safety critical fault tasks that need to be processed immediately.

9. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, Step S5 specifically includes: screening schedulable nodes with sufficient CPU, memory, GPU, and network resources to meet the requirements of the model container to be expanded; selecting the target node and generating expansion instructions; adding corresponding model container replicas according to the model type; allocating batch tasks to the newly added replicas for parallel execution; if there are no available nodes, recording the resource shortage status and waiting or issuing an alarm.

10. A containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, Step S6 specifically includes: for high-priority fault tasks, first query the currently available model container replicas; if there are idle replicas, immediately allocate and execute them; if there are no idle replicas, check if there are low-priority tasks occupying resources. When it is possible to pause or postpone, low-priority tasks are paused or postponed and resources are released; otherwise, the elastic scaling control module triggers rapid expansion, starts an emergency container copy and reserves CPU, GPU and memory resources, then performs high-priority fault diagnosis and outputs results first; rapid expansion is not constrained by the comprehensive load score threshold.

11. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, Step S7 further includes: when the overall load score reaches the expansion candidate threshold, a high-priority fault diagnosis task occurs, or the overall load score is continuously lower than the reduction threshold, the system switches to batch diagnosis of high-load scenario, sudden fault diagnosis scenario, and low-load idle scenario, respectively.

12. The containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, Specifically, step S8 includes the following steps: when the task queue length, CPU utilization, memory utilization, and GPU utilization are all below a preset threshold for multiple consecutive time windows, and there are no high-priority tasks, the system performs a scaling down.

13. A containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, Step S8 specifically includes: when the low load continues for more than a time window, calculate the number of model container replicas that can be reduced; if the number of model container replicas after reduction is lower than the minimum number of service replicas, retain the minimum number of service replicas and continue monitoring; otherwise, send a reduction instruction to the container orchestration platform, stop redundant model container replicas, release CPU, GPU and memory resources and reclaim idle nodes to the resource pool, record the reduction result and enter the cooling time.

14. A containerized elastic resource scheduling method for a fault diagnosis model according to claim 1, characterized in that, The method further includes step S9: calculating the average waiting time of tasks, model inference time, task completion rate, and resource utilization rate according to a preset feedback cycle; when the average waiting time of tasks or the model inference time exceeds the target value, reducing the expansion threshold or increasing the number of expansion replicas within a preset adjustment range; when the resource utilization rate is lower than the target value and there are no high-priority tasks, increasing the expansion threshold or decreasing the number of expansion replicas within a preset adjustment range, and using the adjusted parameters for subsequent resource scheduling.

15. A containerized elastic resource scheduling system for a fault diagnosis model, characterized in that, include: The data access module is used to receive vehicle operation data, trackside inspection data, maintenance data and fault log data, and to perform format verification and standardization processing on the data to be diagnosed and task information. The task queue module is used to generate, cache, and manage the fault diagnosis task queue; The task priority scheduling module is used to determine the priority of diagnostic tasks based on fault level, vehicle operating status, task waiting time and business rules, and to perform queue rearrangement and task allocation. The model container management module is used to encapsulate fault diagnosis models and their runtime dependencies into container images, and manage the creation, startup, shutdown, scaling up and down, and health status of model container replicas through the container orchestration platform. The resource monitoring module is used to monitor the CPU utilization, memory utilization, GPU utilization, running status, and idle resources of model containers through the container orchestration platform interface, node monitoring agent, and container runtime interface. The load scoring module is used to calculate the overall load score of the fault diagnosis model service; The business scenario identification module is used to identify high-load batch diagnostic scenarios, sudden fault diagnostic scenarios, normal stable scenarios, and low-load idle scenarios. The elastic scaling control module is used to generate instructions for scaling up and down the model container replica, preheating resources, and releasing resources based on the business scenario identification results. The diagnostic results output module is used to output fault diagnosis results, fault level, maintenance suggestions and early warning information.

Images