Mobile medical oriented internet of vehicles computing service system

Abstract

This invention discloses a vehicle-to-everything (V2X) computing service system for mobile healthcare, comprising a task acquisition module, a data transmission module, a task offloading decision module, a computing processing module, an environmental perception module, and a system management module. It extracts attributes of computing tasks generated by medical vehicles traveling on roads. Based on environmental parameters and resource information, and while satisfying the conflicting interests of participating parties, it focuses on the real-time and versatility requirements of medical V2X, providing efficient, high-quality, and diverse task offloading strategies and processing solutions for medical vehicle data processing and analysis. This provides a high-performance, highly available V2X computing service system for solving computing problems in mobile healthcare services. This invention adopts a multi-module design, combining hardware deployment of computing resources with software design to optimize these issues. A user-friendly and easily expandable system platform is provided to both medical and patient users through a visual interface.

Description

Technical Field

[0001] This invention relates to the technical field of mobile edge computing for medical vehicles, and in particular to a vehicle-to-everything (V2X) computing service system for mobile healthcare. It optimizes the task offloading strategy for mobile computing in medical vehicles by combining multi-objective optimization modeling and algorithms, and ultimately provides high-quality and efficient task computing services. Background Technology

[0002] With the rapid development and widespread application of 5G technology, various mobile terminals are connecting to the internet, leading to an explosive growth in the amount of data within the network. This influx of computing tasks poses a significant challenge to the deployment and use of computing resources. To provide more convenient medical services, medical vehicles are also connecting to the Internet of Vehicles (IoV), enabling them to utilize network resources anytime, anywhere to query relevant data and process patient medical data instantly. This includes patient imaging analysis, case searches, comparisons of related cases, symptom analysis, and extraction of relevant information from medical literature. Due to the specific nature of medical assistance applications, patient treatment requires speed and accuracy, placing high demands on the timeliness and reliability of computing tasks. Simultaneously, considering the universality of the target audience, computing costs should not be excessively high. Therefore, IoV computing services in the medical field have higher requirements for system real-time performance, availability, and reliability.

[0003] To address computing challenges in the Internet of Vehicles (IoV), edge computing service architectures are typically employed. Roadside Units (RSUs) are deployed on one or both sides of the road, including micro base stations (MIBS) with communication capabilities and edge servers (ENs) with computing capabilities. Additionally, various sensors are placed as needed to acquire relevant information. Through wireless communication technologies such as satellite or mobile cellular networks, vehicles communicate with remote cloud data centers, accessing the cloud platform's massive databases and utilizing its abundant computing resources to achieve information exchange and sharing. Vehicle-to-vehicle (V2V) communication technology in IoV establishes communication channels between vehicles, making information exchange between them more convenient. For computationally intensive service scenarios, mobile service vehicles can also be deployed on the road to provide computing resources to user vehicles and handle their computational tasks. Roadside edge servers and service vehicles provide convenient, efficient, and flexible computing resources for computing tasks in IoV.

[0004] Providing computing services to user vehicles requires not only providing hardware computing resources but also rationally offloading tasks to those resources to complete the processing. The quality of task offloading strategies directly impacts user Quality of Service (QoS), computing service provider profits, energy efficiency, and carbon emissions. Therefore, optimizing task offloading strategies is a crucial aspect of connected vehicle computing services. In practical mobile healthcare service scenarios, the importance of various factors is typically weighed, selecting the most critical objective or objectives to establish a single-objective or multi-objective optimization problem model for optimizing the task offloading strategy. Common optimization objectives include: user concerns such as task completion time, monetary costs, service reliability, and user vehicle energy consumption; service provider concerns such as resource utilization, profits, and maintenance costs; and third-party related factors such as total system energy consumption, carbon emissions, network link bandwidth, and transmission power consumption. Besides the objectives to be optimized, the optimization problem also needs to consider constraints within the system, such as limited vehicle energy, the user's expected maximum task completion time and budget, limited edge node resources, data conflicts, and other network limitations.

[0005] With the continuous development of optimization techniques, optimization problems are becoming increasingly complex. Multi-objective optimization problems involving multiple stakeholders are currently a key research focus and a central area of ​​work. Common optimization methods include: mathematical programming methods based on numerical computation, heuristic algorithms primarily using swarm intelligence and genetic algorithms, and optimization methods based on machine learning. Mathematical programming methods exhibit limitations in efficiency when solving complex optimization problems, particularly for non-convex problems, multi-objective problems, and high-dimensional problems, where both computational efficiency and performance are unsatisfactory. Heuristic algorithms demonstrate good search performance globally, showing universality for irregular regions and high-dimensional problems, and their powerful search capabilities are more than capable of optimizing multiple objectives. However, these algorithms require sophisticated algorithm design, flexibly avoiding local optima, especially when optimizing multiple objectives, where diversity and convergence pose significant challenges. Solving specific multi-objective optimization problems, such as the task offloading optimization problem in vehicle networking, requires analyzing the actual problem and optimizing the search strategy. Reinforcement learning (RL), as a novel learning method based on machine learning, has recently been widely researched and used. In the field of task offloading optimization, reinforcement learning is often combined with deep neural networks (DNNs), namely deep reinforcement learning (DRL). A common method is deep Q-learning (DQL), where Markov decision processes (MDPs), temporal difference algorithms (TDs), and deep deterministic policy gradient algorithms (DDPGs) are key technologies in DRL. The reward mechanism and network design of reinforcement learning directly affect the learning effect. For multi-objective optimization, current methods mainly utilize weight coefficients to transform the problem into a single-objective problem, and there are still some challenges in the trade-offs and joint optimization of multiple objectives. In addition, the computational efficiency of reinforcement learning is also a major obstacle to its application in industrial fields.

[0006] In the field of task offloading strategy optimization for mobile computing in medical vehicles, rationally analyzing and modeling multiple objectives that need optimization to form a multi-objective optimization problem that conforms to objective laws and scientific logic, and designing efficient task offloading strategy optimization algorithms, is of great significance for improving the performance and service quality of vehicle-to-everything (V2X) edge computing. This, in turn, greatly promotes the development of medical computing services such as patient treatment and medical data analysis and processing in medical vehicles. Therefore, this invention focuses on combining the real-time and versatility requirements of medical V2X with the interests of all parties involved in edge computing services, providing an edge computing resource deployment system architecture. This architecture offers efficient, high-quality, and diversified task offloading strategies and processing solutions for medical vehicle data processing and analysis, providing a high-performance, highly available V2X computing service system for solving computing problems in mobile medical services. Summary of the Invention

[0007] The purpose of this invention is to extract attributes from the computational tasks of medical vehicles, design an edge computing service architecture, comprehensively consider the interests and needs of all participating parties, provide optimized offloading strategies and efficient computing services for computational tasks, and form a vehicle-to-everything (V2X) computing service system for mobile healthcare that is easily scalable in terms of data and applications and supports heterogeneous deployment in terms of environment and facilities. On the one hand, it solves the technical challenges of optimizing multiple objectives in task offloading decisions by designing a multi-objective optimization algorithm that simultaneously optimizes four objectives: task completion time, user overhead, edge server load balancing, and total system energy consumption, providing diversified and high-quality decision-making solutions for task offloading. On the other hand, it leverages the flexibility of distributed edge computing resources to address the real-time requirements of medical vehicle-to-everything tasks, providing a computing service system suitable for large-scale and diversified mobile task processing. The system adopts a multi-module design approach, and through unified management of key intermediate services, combined with distributed edge computing and network transmission facilities in the system architecture, it provides a computing service platform for mobile medical vehicles that enables timely task processing, effective information exchange, and mutual benefits for all parties.

[0008] To achieve the above objectives, the technical solution provided by this invention is: a vehicle-to-everything (V2X) computing service system for mobile healthcare, comprising:

[0009] The task acquisition module is used to generate computational tasks from medical vehicles, statistically analyze the attributes of these tasks, and obtain task data to be processed and task attribute data. The task attribute data format is standardized.

[0010] The environmental perception module is used to count the available resources in the computing service system, obtain computing resource status information, acquire network environment status information, perceive the location and speed of the medical vehicle, and obtain vehicle status information.

[0011] The task offloading decision module establishes a multi-objective optimization problem model based on the interests of all parties involved, including computing service users, providers, and public resource management. It then uses a task offloading optimization algorithm to obtain a task offloading strategy based on task attribute data, computing resource status, and vehicle status information.

[0012] The data transmission module, based on computing resource location and vehicle location information, and according to the task offloading strategy, utilizes V2I communication technology to realize the uploading and downloading of computing task data;

[0013] The computing processing module provides computing resources to process arriving tasks. The facilities that provide computing resources include: the vehicle itself, edge servers deployed on one side of the road, and cloud data centers in a remote location.

[0014] The system management module is the external functional module of the computing service system. Through visual operation, it provides management capabilities for services, applications, and corresponding data and tasks, including user access, resource management, management of the interests of participating parties, information display, and access control.

[0015] Furthermore, the specific details of the task acquisition module are as follows:

[0016] Medical vehicles generate a variety of computational tasks, including image analysis, image processing, data querying, case matching, case analysis, and medical history tracking. These tasks vary in size, computational load, and timeliness requirements. Local vehicles can handle some simple tasks with low computational load, while other tasks that cannot be handled by the current vehicle require remote processing. The process involves extracting the attributes of the tasks to be processed, including task size, computational load, required memory, maximum completion time, and the vehicle number to which the task belongs. The tasks are then numbered and the data is stored in a JSON-formatted configuration file. The data is stored in arrays, each array containing the aforementioned task attribute fields and values, separated by commas. The number of tasks is counted and recorded in the JSON file.

[0017] Furthermore, the specific details of the data transmission module are as follows:

[0018] The hardware foundation of this module is the network link in the system. Tasks that need to be processed remotely are transmitted from vehicles to remote servers via V2I technology. Due to distance limitations, the vehicles generating tasks sometimes cannot communicate directly with the computing resources corresponding to the task offloading strategy. In such cases, transmission needs to be carried out through micro base stations or macro base stations. However, base station transmission also has distance limitations, and sometimes multiple base stations are required. Based on the vehicle location information and computing resource location information, combined with the network environment status, the most convenient and high-speed data transmission channel is constructed to realize data transmission.

[0019] Furthermore, the specific details of the task unloading decision module are as follows:

[0020] The task offloading decision module is the core module of the computing service system. First, a multi-objective optimization problem model is established based on the interests of all parties involved, including users, service providers, and public resource management. Then, a near-Pareto solution set is obtained using a multi-objective optimization algorithm for task offloading. Finally, based on the actual situation, the final task offloading strategy is selected and sent to the data transmission module to guide each task to be transmitted to the target server and complete the offloading.

[0021] The construction of the multi-objective optimization problem model refers to: establishing a function expression representing the value of the optimization objective function or the merits of the optimization objective, as well as function expressions representing various constraints existing during the task unloading process, based on the mathematical and logical relationships between the optimization objective, task parameters, and environmental parameters; considering the special nature of medical services, the first step is to optimize the task completion time to ensure timely completion; secondly, to optimize computational costs, reduce treatment costs, and provide affordable medical services for ordinary patients; finally, based on considerations of the commercial operation of medical services, in order to reduce server maintenance costs and extend server lifespan... Optimize load balancing on edge servers; finally, given the massive scale of the computing service system, the high participation of patients and medical vehicles, and the extensive use and deployment of computing resources, high-performance computing consumes a large amount of energy, and the environmental protection issues related to carbon emissions cannot be ignored, so it is necessary to optimize the total energy consumption of the system; therefore, the optimization objectives include: average task completion time, total system energy consumption, average task overhead, and load balancing of edge nodes; in order to ensure the availability of the task offloading scheme, the optimization problem needs to be constrained by the following constraints: CPU, memory, and energy resource constraints on various computing nodes, maximum task completion time constraints, and edge node resource utilization constraints;

[0022] Let the task set in the computing service system be T = {m1, m2, ..., m}. M The set of vehicles is V = {v1, v2, ..., v}. nv The edge servers, i.e., the ES set, are E = {e1, e2, ..., e}. N} where M, nv, and N represent the number of tasks, vehicles, and edge servers, respectively, and m, v, and e represent individual tasks, vehicles, and edge servers, respectively, with subscripts indicating their numbers; the communication facilities include micro base stations (MIBS) and macro base stations (MABS), with MIBS deployed together with ES and MABS deployed together with the cloud data center; the specific modeling of the above optimization problem is as follows:

[0023] a. Average task completion time

[0024] The goal is to minimize the average completion time of tasks. Tasks executed on different servers will have different completion times; i represents the task number, and task m... i The completion time is expressed as:

[0025]

[0026] in, Representing task m respectively i The time it takes for data to be transmitted from the vehicle to the target server (upload time), waiting time, execution time, and the time it takes for the calculation results to be returned to the vehicle (also known as return time) are all considered part of the timeframe. iRepresents task m i Completion time;

[0027] For tasks performed on local vehicles, the upload time, waiting time, and return time are as follows. Both are 0, therefore we have

[0028] For tasks executed on edge servers, both upload and return times are calculated as the ratio of the task data volume to the corresponding network transmission rate; waiting time... Prediction using queuing theory;

[0029] The specific calculation methods for upload time, execution time, and return time are as follows:

[0030]

[0031]

[0032]

[0033] Among them, s i and r i Representing task m respectively i The amount of data to be uploaded and the amount of data to be returned, r v2e r e2e and r e2v These represent the transmission rates from vehicle to MIBS, between MIBS, and from MIBS to vehicle, respectively. The transmission rates are calculated using Shannon's formula. α and β represent the number of MIBSs required for the upload and download links, respectively. i Represents task m i The calculated density, f i This indicates that the task m is assigned to it. i Computing resources;

[0034] For tasks executed in cloud data centers, their upload time and return time are calculated based on their transmission path using the following methods:

[0035]

[0036]

[0037] Where, r e2c r c2e These represent the transmission rates along the MIBS to MABS and MABS to MIBS transmission paths, respectively; therefore, the average task completion time is expressed as:

[0038]

[0039] Where delay is the average completion time of all tasks, and i is the task number;

[0040] b. Average computational cost

[0041] The overhead of remote computing services will be discussed in three cases:

[0042] If the tasks are executed locally, the cost of each task is 0, that is, task m i The cost is i =0, because local vehicles are not charged.

[0043] If a task is executed on an edge server, i.e., an edge node, the cost of each task is the execution time multiplied by the price per unit time of the server, i.e., task m. i The cost is Where x i,j Represents task m i Is it at edge node e? j If executed, the value is 1; otherwise, the value is 0. j It is the edge node e j The price, where j is the edge node number;

[0044] If the task is executed on a cloud server, then task m i The expense is Among them price c This is the price per unit of time for cloud servers;

[0045] Therefore, the average computational cost of the task, Cost, is expressed as:

[0046] c. Load balancing

[0047] c1. Calculate the load on each edge node:

[0048] edge node e j The total resources required for the uploading and unloading tasks are:

[0049]

[0050] in, Represents edge node e j CPU resources used Represents edge node e j The memory resources occupied by the s i c i It is task m i Required CPU resources, mem i It is task m i Required memory resources;

[0051] edge node ej The load is:

[0052]

[0053] Among them, CA j and MA j They represent edge nodes e respectively. j The sum of CPU and memory resources; and They represent edge nodes e respectively. j CPU load and memory load;

[0054] c2. Calculate the average load of edge nodes:

[0055]

[0056] in, This represents the average load on CPU resources. This indicates the average load on memory resources;

[0057] c3. Express the load balancing of computation nodes using variance:

[0058]

[0059] Among them, lb com and lb mem These represent the differences in CPU and memory load at edge nodes, respectively.

[0060] Therefore, the load balancing metric LB is: To achieve a more balanced load, the load balancer (LB) needs to be minimized.

[0061] d. Total energy consumption

[0062] Based on the relationship between power and CPU frequency, p ~ K*f 3 Where p, K, and f are power, power consumption coefficient, and CPU frequency, respectively, and the relationship between energy consumption and power is E = p * t, where E and t are energy consumption and working time, respectively. The following task m is obtained. i energy consumption i The calculation formula is as follows:

[0063] If the task is executed locally, then:

[0064] If the task is executed at the edge, then: Among them, energy consumption is calculated. Transmission power consumption

[0065] and These represent the transmission power along the transmission paths from vehicle to MIBS, between MIBS, and from MIBS to vehicle. These are the upload energy consumption and the return energy consumption, respectively.

[0066] If the task is executed in a cloud data center, then: Among them, energy consumption is calculated. Transmission power consumption These represent the transmission power along the MIBS to MABS and MABS to MIBS transmission paths, respectively.

[0067] Therefore, the total energy consumption of the system is:

[0068] e. Optimize problem modeling

[0069] The optimization issues can be summarized as follows:

[0070]

[0071] St

[0072] 1) delay i ≤ddl i

[0073] 2).

[0074] 3).

[0075] 4).

[0076] 5).

[0077] 6).

[0078] 7).

[0079] 8).xl i ,x i,j ,xc i ∈{0,1}

[0080] The four minimization formulas for the optimization problem represent: minimizing the average task completion time, minimizing the total system energy consumption, minimizing load balancing, and minimizing the average task computational cost.

[0081] The constraints are as follows: Rule 1 states that the completion time of each task does not exceed the maximum completion time of the task; Rule 2 states that the local computing energy consumption of the vehicle does not exceed the vehicle's energy consumption; Rule 3 states that the CPU resources required for executing tasks on the vehicle do not exceed the vehicle's CPU computing power; Rule 4 states that the memory required for processing tasks by the vehicle does not exceed the vehicle's memory; Rule 5 states that the computational load of each edge server processing tasks does not exceed its own CPU resources; Rule 6 states that the memory usage of each edge server processing tasks does not exceed its own memory resources; Rule 7 states that the computational load of each edge server must be higher than the minimum load threshold; Rule 8 is a binary variable constraint, xl i x i,j xc i Representing task m respectively i Is it on local or edge node e? j Executed in cloud data centers; value is 1 if applicable, 0 otherwise; ddl i This represents the maximum completion time threshold for the i-th task. These represent the available energy, available CPU, and available memory of the nth vehicle, respectively. They represent edge nodes e respectively. j Available CPU and memory, l thr This represents the minimum CPU load threshold for edge nodes;

[0082] Among them, the multi-objective optimization algorithm refers to the design of heuristic optimization algorithms based on multi-objective optimization problems, using swarm intelligence algorithms, genetic algorithms and other related methods, and adopting a combination of multiple strategies to design an effective task unloading multi-objective optimization algorithm MaOITGO-TO to solve the above-mentioned multi-objective optimization problems;

[0083] MaOITGO-TO, based on tumor cell growth patterns and considering the specificities of task unloading scenarios, incorporates multiple strategies. Utilizing tumor cell growth patterns, it searches the decision space in various ways, employing a Pareto optimal strategy to solve the aforementioned optimization problem, yielding a near-Pareto solution set. MaOITGO-TO categorizes tumor cells into four types: dead cells, dormant cells, growing cells, and invading cells, designing different search methods for each cell type. Dead cells serve to store all non-dominated solutions, dormant cells undergo fine-grained searching, growing cells undergo coarse-grained searching, and invading cells undergo a skip-style search.

[0084] Let the cell coordinates in MaOITGO-TO be center={center1,center2,...,center}. M}, where M is the number of tasks, i.e., the dimension of the decision space, center1, center2, ..., center MThe values ​​of the 1st, 2nd, ..., Mth dimensions of the cell coordinates represent the execution nodes of the 1st, 2nd, ..., Mth tasks. The MaOITGO-TO encoding encodes the execution node corresponding to the local execution of the task as 0, and the execution node corresponding to the task in the cloud data center as N+1, which is the number of edge nodes plus one. If the task is executed on the edge server, the encoding corresponds to the edge server number, which is 1 to N. Each cell coordinate corresponds to a point in the target space, which is the fitness value, and its structure is fitness = {fitness1, fitness2, fitness3, fitness4}, which represent the function values ​​of the average completion time, total energy consumption, load balancing, and average cost of the target task, respectively.

[0085] Furthermore, the specific steps of MaOITGO-TO are described as follows:

[0086] Step 1: Initialize the cell population, set the population size to pop_size, that is, the number of cells in the population is pop_size; initialize 4 types of cells, namely: determine the set of nodes with corresponding computing power according to the memory size required for task execution, and semi-randomize to generate four cell populations: all tasks are executed at the edge, tasks are executed at the edge and cloud, tasks are executed locally and at the edge, and tasks are executed locally, at the edge and cloud.

[0087] Step 2: Calculate the rank of each cell using the non-dominated sorting algorithm, denoted by rank. Classify cells into dormant cells, growing cells, and invading cells according to their rank, with each type representing a proportion of num cells. q ,num p ,num it And add all currently non-dominated solutions to the dying cell;

[0088] Step 3: Dormant cells perform fine-grained searches. Half of the dormant cells are guided forward by extreme points, which are the points where the minimum value is located on the four targets. The formulas for advancing speed and position update are as follows:

[0089] v i (t′+1)=w*v i (t′)+c*r*(y i -x i )

[0090] center i (t′+1)=center i (t′)+v i (t′+1)

[0091] Among them, y i The coordinates of the extreme point, x i This is the cell's current coordinates; centeri (t′) is the original coordinate of the i-th dimension of the cell, center i (t′+1) is the new coordinate of the i-th dimension of the cell, where t′ represents the current time and t′+1 represents the next time. i (t′) is the current velocity, v i (t′+1) is the updated velocity, and the cell dimensions are distributed with probability p. q Move forward or remain unchanged;

[0092] The other half of the dormant cells move forward according to the optimization goal, and each dimension of the cell is determined by probability p. q The options are as follows: (Changes or no changes will be made.)

[0093] a. Minimize task completion time: Migrate the task to a cloud data center;

[0094] b. Minimize total energy consumption: Migrate tasks on cloud data centers or high-power edge servers to low-power edge servers;

[0095] c. Minimize load balancing: Migrate tasks on edge nodes with above-average load to edge nodes with below-average load;

[0096] d. Minimize computational overhead: Migrate tasks from cloud data centers or expensive edge servers to cheaper edge servers or local vehicles;

[0097] Step 4: The growing cell moves forward guided by the global optimum. There are two strategies for selecting the global optimum. One is to divide the non-dominated solutions into regions based on the distance from the non-dominated solution to the reference point, calculate the density of the non-dominated solutions, and select the non-dominated solution with the smallest density as the global optimum. The other is to use the roulette wheel method to select a non-dominated solution as the global optimum.

[0098] The formulas for the rate and location update of growing cells are:

[0099] v i (t′+1)=w*v i (t′)+c1*r1*(y1 i -x i )+c2*r2*(y2 i -x i )

[0100] center i (t′+1)=center i (t′)+v i (t′+1)

[0101] Among them, y1 i and y2 iThese represent the coordinates of two global optimal points, w, c1, and c2 are parameters, and r1 and r2 are random numbers between 0 and 1;

[0102] Step 5: The invading cell performs a crossover operation, employing two crossover strategies. One strategy involves the invading cell exchanging partial dimension values ​​with two global optima, namely: center i =y1 i or center i =y2 i Another approach is to randomly select one of the two global optima as the optimal point, and then simulate binary crossover between the invading cell and the optimal point.

[0103] center i 1 =0.5×[(1+γ)*center i +(1-γ)*z i ]

[0104] center i 2 =0.5×[(1-γ)*center i +(1+γ)*z i ]

[0105] Among them, center i This represents the coordinate of the i-th dimension of the invading cell that needs to perform the crossover operation, z. i This represents the coordinate of the i-th dimension of the optimal point. and Let represent the coordinates of the invading cell currently performing the crossover operation and the global optimum in the i-th dimension, respectively; γ is randomly determined by the distribution factor η according to the following formula, where η is a user-defined parameter:

[0106]

[0107] Where rand is a random number between 0 and 1;

[0108] Step 6: Perform non-dominated sorting on the newly generated cells, add dead cells to the non-dominated solutions, update the dead cells, and remove the dominated solutions;

[0109] Step 7: Determine if the iteration termination condition is met, i.e., whether the maximum number of iterations MAX_FES has been reached; if the iteration termination condition is met, output the coordinates and fitness values ​​of all dead cells and end the algorithm; otherwise, perform non-dominated sorting on the cell population, and sort the cells proportionally to their rank values ​​(num). q ,num p ,num it Reclassify dormant cells, growing cells, and invading cells, and return to step 3.

[0110] Furthermore, the specific details of the computation processing module are as follows:

[0111] Based on physical computing resources, the system executes computational tasks. The hardware includes the vehicle's own computing resources, roadside edge servers, and servers in a cloud data center. Tasks are transferred to computing nodes for processing according to a task offloading strategy. The vehicle itself, the roadside edge servers, and the remote cloud data center can all perform computational processing. Upon receiving a task, the computing node generates a task queue and processes tasks in the queue according to a first-come, first-served strategy. Each server has heterogeneous computing capabilities, with servers performing computations on a virtual machine basis. Therefore, the computing module provides different levels of computing services, including diverse computing efficiencies, rental prices, and power consumption, improving the system's versatility to handle diverse user tasks.

[0112] Furthermore, the specific details of the environmental perception module are as follows:

[0113] The hardware foundation of this module is the Roadside Unit (RSU) located on one side of the road, which includes a Micro Base Station (MIBS) and an Edge Server (ES). The micro base station, in addition to data transmission, is used to sense network status and promptly report network faults or congestion information. The edge server, besides task processing, is used to sense computing resource information and promptly report resource fault information. Additionally, the roadside unit has a sensor to sense the position and speed of vehicles within its signal range, sending this information to the task offloading decision module as part of the parameters for the multi-objective optimization problem. When there are changes in network or computing resources, the change information is sent to the task offloading decision module, which modifies the parameters within the multi-objective optimization problem model accordingly. Vehicle position and speed, along with network status statistics, constitute environmental parameters, while computing resource status statistics constitute resource information.

[0114] Furthermore, the specific details of the system management module are as follows:

[0115] The underlying modules are encapsulated into APIs, enabling the system to be accessed by users with different identities through visual operations, allowing for data and resource management. This includes access for vehicle users, computing service providers, and system maintainers. Vehicle users can view and modify service requirements, including maximum task completion time, expected overhead, and expected task completion time, as well as view the provider's historical service quality assessment, i.e., service reliability. Computing service providers can view and modify resource configurations, including resource usage limits, i.e., minimum resource utilization and server load limits, rental prices of various servers, adding or removing equipment, and viewing current resource usage for adjustments and maintenance. System maintainers can view the optimization problem model and algorithm execution status, facilitating problem identification and timely handling. Authorized medical staff and patients can view system usage information, including system coverage, number of connected vehicles, server prices, and service quality evaluations—publicly available information that helps patients understand the system, builds confidence in disease treatment, and ensures patient rights through price transparency.

[0116] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0117] 1. This invention provides a complete service system for mobile computing in medical vehicles, from hardware facilities to software deployment. It offers flexible and abundant edge computing resources and solutions for computing tasks with high real-time requirements, reduces data transmission costs, lowers computing overhead, and ensures the timeliness of patient treatment and the universality of medical expenses.

[0118] 2. The edge computing architecture adopted in this invention reduces the cost for computing service providers. The feature that allows for heterogeneous deployment of edge servers makes the deployment of hardware facilities more flexible and convenient. Servers distributed at the network edge do not have high performance requirements, which can reduce deployment and update costs. The distributed computing architecture can also alleviate the pressure on network transmission, reduce the requirements for network components and bandwidth, thereby reducing the provider's operation and maintenance costs, which is in line with its commercial operation model.

[0119] 3. As a service system, this invention breaks through the limitations of traditional systems that only consider a single objective in terms of service quality and efficiency. It can comprehensively consider the needs of multiple parties, including patients, medical staff and other users, providers and environmental protection, and fully optimize four optimization objectives, including: task completion time and computing overhead that users care about, edge server load balancing that is related to the interests of providers, and total system energy consumption in response to the call for environmental protection.

[0120] 4. The task offloading decision module of this invention includes a heuristic multi-objective optimization algorithm, which solves the limitations of traditional algorithms in optimizing more than three objectives. It has significant optimization effects on four objectives and preserves the near Pareto solution set. This provides a variety of selectable task offloading schemes for computing services and greatly satisfies the interests of all participating parties. Attached Figure Description

[0121] Figure 1 This is a schematic diagram of the deployment of the system of the present invention.

[0122] Figure 2 This is an architecture diagram of the system of the present invention.

[0123] Figure 3 This is a data transmission path diagram of the system of the present invention.

[0124] Figure 4 This is a flowchart of the task processing in the server of the system of the present invention.

[0125] Figure 5 This is a schematic diagram of the system management module. Detailed Implementation

[0126] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0127] The main objective of this invention is to provide real-time, high-quality computing services for medical vehicles on the road. Considering the mobility of medical vehicles, the real-time nature of medical computing tasks, and the universality of cost, a heterogeneous distributed edge computing architecture is designed. A multi-objective optimization problem model is established, and a heuristic search-based optimization algorithm is proposed, thereby providing diverse task offloading solutions. The system deployment is as follows... Figure 1 As shown, several medical vehicles are traveling on a two-way, multi-lane road. A series of roadside devices, including edge servers, micro base stations, and sensors, are distributed along one side of the road. The signal range of the micro base stations covers the entire road with a certain diameter. The cloud data center is located relatively far from the road and is communicated by macro base stations. The system architecture is as follows... Figure 2 As shown, the system generates a computational task and extracts its task attributes; roadside equipment senses the environment and obtains environmental parameters; these parameters are transmitted to the task unloading decision module, which uses an optimization algorithm to obtain a task unloading plan; the task data is transmitted to the computation processing module via the data transmission module, which unloads the task according to the task unloading plan, ultimately completing the task processing. The entire system interacts with the outside world through the system management module, allowing administrators to view or modify internal system data and settings through a visual window, and to maintain the system's hardware and software.

[0128] The vehicle-to-everything (V2X) computing service system for mobile healthcare provided in this embodiment includes a task acquisition module, an environment perception module, a task offloading decision module, a data transmission module, a computing processing module, and a system management module. The specific implementation principles of each module are explained below.

[0129] 1. Task Acquisition Module

[0130] Medical vehicles generate a variety of computational tasks, including image analysis, image processing, data querying, case matching, and case analysis. These tasks vary in size, computational load, and timeliness requirements. In addition to packaging the task data, it is also necessary to collect task attribute information, such as the task data volume, computational load (computational density), expected result data volume, memory required for execution, vehicle number, and maximum completion time. This attribute information is stored in a JSON file, as shown in the example below:

[0131] {"Size":1992756.110164173,"Memory":1.992756110164173E9,"TVid":99,"CPUDemand":1000,"Result":1,"Deadline":3}

[0132] Wherein, "Size" refers to the data volume of the task (bits), "Memory" refers to the memory required for task execution (bits), "TVid" refers to the vehicle number that generated the task, "CPUDemand" refers to the computational density of the task, multiplied by the data volume to obtain the computational load (cycles), "Result" refers to the expected data volume of the task's computational result, which is a ratio, multiplied by the data volume to obtain the expected result data volume, and "Deadline" is the maximum completion time of the task (seconds). The task attribute format extracted for each vehicle is as follows:

[0133] {"TASKS":[…],"FLAG":"Task Property","Number":num}

[0134] The "[...]" section contains the specific attributes of each of the aforementioned tasks, separated by commas. "FLAG" is the field label, indicating that the label for this row of data is "Task Property," and "Number" indicates the number of tasks contained in this row of data.

[0135] 2. Data transmission module

[0136] The hardware foundation for this module is the network link within the system. Tasks requiring remote processing are transmitted from the vehicle to the corresponding server via V2I technology, according to the offloading plan. The data transmission path is as follows: Figure 3As shown, due to the limitations of distance and signal range, vehicles generating tasks sometimes cannot directly communicate with the corresponding computing resources in the task offloading strategy. Therefore, transmission via micro base stations (MIBS) or macro base stations (MIBS) is necessary. Task data to be offloaded to the edge server is first transmitted to the initial micro base station, which is the micro base station closest to the vehicle generating the task. Since micro base station transmission also has distance limitations, it sometimes needs to pass through multiple micro base stations before finally reaching the target micro base station, and then to the target server for processing. Task data to be offloaded to the cloud data center is first transmitted from the vehicle to the initial micro base station, and then directly to the macro base station at the cloud data center, and finally to the cloud data center for processing. The main function of this module is to construct the most convenient and high-speed data transmission channel based on vehicle location information, computing resource location information, and network environment status to achieve data transmission.

[0137] 3. Task Unloading Decision Module

[0138] In computing architecture, the design of task offloading schemes is a core issue. Offloading tasks to different servers has a significant impact on the service quality and effectiveness of the service system. Therefore, the task offloading decision module is the core module of this invention. Considering the special nature of medical services, the first step is to optimize task completion time to ensure timely completion. Secondly, the computational overhead needs to be optimized to reduce treatment costs and provide affordable medical services to the general public. Then, based on considerations of the commercial operation of medical services, the load balancing of edge servers needs to be optimized to reduce server maintenance costs and extend server lifespan. Finally, given the large scale of the system, the high participation of patients and medical vehicles, and the extensive use and deployment of computing resources, high-performance computing consumes a large amount of energy, and environmental issues such as carbon emissions cannot be ignored; therefore, the total energy consumption of the system needs to be optimized. Taking into account the interests of users and providers, as well as the call for environmental protection and green energy, a multi-objective optimization problem model is established to collaboratively optimize four objectives: task completion time, computational overhead, total system energy consumption, and edge server load balancing. Then, based on the characteristics of the above optimization problem, an optimization algorithm based on heuristic search is designed to optimize four objectives simultaneously and provide a variety of task unloading schemes for selection.

[0139] Let the set of tasks in the system be T = {m1, m2, ..., m}. M The set of vehicles is V = {v1, v2, ..., v}. nv The set of edge servers is E = {e1, e2, ..., e}. N} where M, nv, and N represent the number of tasks, vehicles, and edge servers, respectively, and m, v, and e represent individual tasks, vehicles, and edge servers, respectively, with subscripts indicating their numbers. The specific modeling of the above optimization problem is as follows:

[0140] (1) Average task completion time

[0141] The objective is to minimize the average completion time of the tasks. Tasks executed on different servers will have different completion times. Let 'i' represent the task number, and 'm' represent the task... i The completion time is expressed as:

[0142]

[0143] in, Representing task m respectively i The time it takes for data to be transmitted from the vehicle to the target server (upload time), waiting time, execution time, and the time it takes for the calculation results to be returned to the vehicle (also known as return time) are all considered part of the timeframe. i Represents task m i The completion time.

[0144] For tasks performed on local vehicles, the upload time, waiting time, and return time are as follows. Both are 0, therefore we have

[0145] For tasks executed on edge servers, the transmission path is as follows: Figure 3 As shown, both upload and return times are calculated as the ratio of the task data volume to the corresponding network transmission rate.

[0146] The specific calculation methods for upload time, execution time, and return time are as follows:

[0147]

[0148]

[0149]

[0150] Among them, s i and r i Representing task m respectively i The amount of data to be uploaded and the amount of data to be returned, r v2e r e2e and r e2v These represent the transmission rates from the vehicle to the MIBS, between MIBS stations, and from the MIBS to the vehicle, respectively. The transmission rate is calculated using Shannon's formula. α and β represent the number of MIBSs required for the upload and download links, respectively. i Represents task m iThe calculated density, f i This indicates that the task m is assigned to it. i Computing resources.

[0151] Waiting time is predicted using queuing theory. Assume the task arrival time interval follows a negative exponential distribution with parameter λ (λ tasks arrive per second), and the system has s servers (s represents the number of edge servers). The service time of each server is independent and follows a negative exponential distribution with parameter μ (each server can process μ tasks per second). Let p... n Let P{N=n}, where n=0,1,2,... be the probability distribution of queue size N=n after the system reaches a stable state. The specific method for calculating the average task waiting time is as follows:

[0152]

[0153]

[0154]

[0155] Among them, L q P0 is the queue length in the queuing system, P0 is the probability that the number of customers in the system is 0, and W is the number of customers in the system. q It represents the average waiting time for customers in the system. It is the total service intensity of the system, and the average service intensity of the service desk. Waiting time

[0156] For tasks executed in cloud data centers, their upload time and return time are based on... Figure 3 The transmission path shown can be calculated using the following method:

[0157]

[0158]

[0159] Where, r v2e r e2c r c2e r e2v These represent the transmission rates along the vehicle-to-MIBS, MIBS-to-MABS, MABS-to-MIBS, and MIBS-to-vehicle transmission paths, respectively. Therefore, the average task completion time is expressed as:

[0160]

[0161] Where M represents the number of tasks, delay is the average completion time of all tasks, and i is the task number. i It is task m i The completion time.

[0162] (2) Average computational cost

[0163] The overhead of remote computing services will be discussed in three cases:

[0164] If the tasks are executed locally, the cost of each task is 0, that is, task m i The cost is i =0, because local vehicles are not charged.

[0165] If the task is executed on an edge server (i.e., an edge node), the cost of each task is the computation time multiplied by the price per unit time of the server, i.e., task m. i The expense is Where x i,j This represents task m i Is it at edge node e? j Execute; if yes, the value is 1; otherwise, the value is 0. (price) j It is the edge node e j The price. j is the edge node number.

[0166] If the task is executed on a cloud server, then task m i The expense is Among them price c This is the price per unit of time for a cloud server.

[0167] Therefore, the average computational cost of the task, Cost, is expressed as:

[0168] (3) Load balancing

[0169] c1. Calculate the load on each edge node:

[0170] edge node e j The total resources required for the uploading and unloading tasks are:

[0171]

[0172] in, Represents edge node e j CPU resources used Represents edge node e j The memory resources occupied. i c i It is task m i Required CPU resources, mem i It is task m i Required memory resources.

[0173] edge node e j The load is:

[0174]

[0175] Among them, CA j and MA j They represent edge nodes e respectively. j The sum of CPU and memory resources. and They represent edge nodes e respectively. j CPU load and memory load.

[0176] c2. Calculate the average load of edge nodes:

[0177]

[0178] in, This represents the average load on CPU resources. This represents the average load on memory resources. j is the edge node number, and N is the number of edge nodes.

[0179] c3. Express the load balancing of computing nodes using variance.

[0180]

[0181] Among them, lb com and lb mem These represent the differences in CPU and memory load at edge nodes, respectively.

[0182] Therefore, the load balancing metric LB is: To achieve a more balanced load, the load balancer (LB) needs to be minimized.

[0183] (4) Total energy consumption

[0184] This objective aims to minimize the system's total energy consumption, thereby reducing carbon emissions, protecting the environment, and conserving energy. Based on the relationship between power and CPU frequency, p ~ K*f 3 Where p, K, and f are power, power consumption coefficient, and CPU frequency, respectively, and the relationship between energy consumption and power is E = p * t, where E, p, and t are energy consumption, power, and working time, respectively, resulting in the following task m. i energy consumption i The calculation formula is as follows:

[0185] If the task is executed locally, then:

[0186] If the task is executed at the edge, then: Among them, energy consumption is calculated. Transmission power consumption

[0187] and These represent the transmission power along the transmission paths from vehicle to MIBS, between MIBS, and from MIBS to vehicle. These are the power consumption for uploading and the power consumption for returning, respectively.

[0188] If the task is executed in a cloud data center, then: Among them, energy consumption is calculated. Transmission power consumption and These represent the transmission power along the transmission paths from vehicle to MIBS, from MIBS to MABS, from MABS to MIBS, and from MIBS to vehicle.

[0189] Therefore, the total energy consumption of the system is:

[0190] (5) Optimization problem modeling

[0191] The optimization issues can be summarized as follows:

[0192]

[0193] St

[0194] 9) delay i ≤ddl i (The completion time for each task shall not exceed the maximum completion time for the task.)

[0195] 10). (The vehicle's locally calculated energy consumption does not exceed the vehicle's energy consumption.)

[0196] 11). (The CPU required for tasks processed by the vehicle does not exceed the vehicle's CPU capacity.)

[0197] 12). (The memory required for the tasks processed by the vehicle does not exceed the vehicle's memory.)

[0198] 13). (Edge server CPU resource constraints)

[0199] 14). (Edge server memory constraints)

[0200] 15). (The computational load of a single edge node exceeds the minimum threshold)

[0201] 16).xl i ,x i,j ,xc i ∈{0,1} (binary variable constraint, representing task m respectively) i Is it on local or edge node e?j (Executed in cloud data centers; value is 1 if applicable, otherwise 0)

[0202] Among them, ddl i This represents the maximum completion time threshold for the i-th task. These represent the available energy, available CPU, and available memory of the nth vehicle, respectively. They represent edge nodes e respectively. j Available CPU and memory, l thr This represents the minimum CPU load threshold for edge nodes.

[0203] The above multi-objective optimization algorithm is designed as follows:

[0204] To address the aforementioned multi-objective optimization problem, based on tumor cell growth patterns and combining algorithms such as swarm intelligence and genetic algorithms, and considering the specificities of the task unloading scenario, a multi-objective optimization algorithm, MaOITGO-TO, is designed to provide diverse and selectable unloading strategies for task unloading.

[0205] MaOITGO-TO utilizes the growth patterns of tumor cells to search the decision space in multiple ways, employing a Pareto optimal strategy to solve the aforementioned optimization problem and obtain a near-Pareto solution set. MaOITGO-TO categorizes tumor cells into four types: dead cells, dormant cells, growing cells, and invasive cells, designing different search methods for each type. Dead cells serve to store all non-dominated solutions; dormant cells undergo fine-grained searching; growing cells undergo coarse-grained searching; and invasive cells undergo a skip-search approach. This achieves an effective and efficient search, ensuring both convergence and versatility of the algorithm.

[0206] Let the cell coordinates in MaOITGO-TO be center={center1,center2,...,center}. M}, where M is the number of tasks, i.e., the dimension of the decision space, center1, center2, ..., center MThis represents the values ​​of the 1st, 2nd, ..., Mth dimensions of the cell coordinates, i.e., the execution node of the 1st, 2nd, ..., Mth task. The algorithm encodes the execution node corresponding to local task execution as 0, and the execution node corresponding to task execution in the cloud data center as N+1, i.e., the number of edge nodes incremented by one. If the task is executed on an edge server, the encoding corresponds to the edge server number, i.e., 1 to N. Each cell coordinate corresponds to a point in the target space, i.e., the fitness value, whose structure is fitness = {fitness1, fitness2, fitness3, fitness4}, representing the function values ​​of four optimization objectives: average task completion time, total energy consumption, load balancing, and average cost. The specific steps of MaOITGO-TO are described below:

[0207] Step 1: Initialize the cell population, setting the population size to pop_size, which is the number of cells in the population. To accelerate convergence and increase diversity, four types of cells are initialized: based on the memory required for task execution, a set of nodes with corresponding computing power is determined, and four cell populations are generated semi-randomly: tasks are executed entirely at the edge, tasks are executed at the edge and in the cloud, tasks are executed locally and at the edge, and tasks are executed locally, at the edge, and in the cloud.

[0208] Step 2: Calculate the rank of each cell using the non-dominated sorting algorithm, denoted by rank. Classify cells into dormant cells, growing cells, and invading cells according to their rank, with each type representing a proportion of num cells. q ,num p ,num i And add all currently non-dominated solutions to the dead cell.

[0209] Step 3: Dormant cells perform fine-grained searches. Half of the dormant cells are guided forward by extreme points, which are the points where the minimum value is located on the four targets. The formulas for advancing speed and position update are as follows:

[0210] v i (t′+1)=w*v i (t′)+c*r*(y i -x i )

[0211] center i (t′+1)=center i (t′)+v i (t′+1)

[0212] Among them, y i The coordinates of the extreme point, x i This is the cell's current coordinates; center i(t′) is the original coordinate of the i-th dimension of the cell, center i (t′+1) is the new coordinate of the i-th dimension of the cell, where t′ represents the current time and t′+1 represents the next time. i (t′) is the current velocity, v i (t′+1) is the updated velocity, and the cell dimensions are distributed with probability p. q Move forward or remain unchanged.

[0213] The other half of the dormant cells move forward according to the optimization goal, and each dimension of the cell is determined by probability p. q The options are as follows: (Changes or no changes will be made.)

[0214] a. Minimize task completion time: Migrate the task to a cloud data center;

[0215] b. Minimize total energy consumption: Migrate tasks on cloud data centers or high-power edge servers to low-power edge servers;

[0216] c. Minimize load balancing: Migrate tasks on edge nodes with above-average load to edge nodes with below-average load;

[0217] d. Minimize computational overhead: Migrate tasks on cloud data centers or high-priced edge servers to lower-priced edge servers or local vehicles;

[0218] Step 4: The growing cell is guided forward by the global optimum. To increase the diversity of the search, there are two strategies for selecting the global optimum. One is to divide the non-dominated solutions into regions based on the distance from the non-dominated solution to the reference point, calculate the density of the non-dominated solutions, and select the non-dominated solution with the lowest density as the global optimum. The other is to use the roulette wheel method to select a non-dominated solution as the global optimum.

[0219] The formulas for the rate and location update of growing cells are:

[0220] v i (t′+1)=w*v i (t′)+c1*r1*(y1 i -x i )+c2*r2*(y2 i -x i )

[0221] center i (t′+1)=center i (t′)+v i (t′+1)

[0222] Among them, y1 i and y2 iThese represent the coordinates of two global optimal points, w, c1, and c2 are parameters, and r1 and r2 are random numbers between 0 and 1.

[0223] Step 5: The invading cell performs a crossover operation. To improve convergence, two crossover strategies are employed. One strategy involves the invading cell exchanging partial dimension values ​​with two global optima, namely: center... i =y1 i or center i =y2 i , where i is the dimension of the exchange; another approach is to randomly select one of the two global optima as the optimum, and then simulate a binary crossover between the invading cell and the optimum.

[0224] center i 1 =0.5×[(1+γ)*center i +(1-γ)*z i ]

[0225] center i 2 =0.5×[(1-γ)*center i +(1+γ)*z i ]

[0226] Among them, center i This represents the coordinate of the i-th dimension of the invading cell that needs to perform the crossover operation, z. i The center represents the coordinate of the i-th dimension of the optimal point. i 1 and center i 2 Let represent the coordinates of the invading cell currently performing the crossover operation and the global optimum in the i-th dimension, respectively. γ is randomly determined by the distribution factor η according to the following formula, where η is a user-defined parameter:

[0227]

[0228] Here, rand is a random number between 0 and 1.

[0229] Step 6: Perform non-dominated sorting on the newly generated cells, add dead cells to the non-dominated solutions, update the dead cells, and remove the dominated solutions;

[0230] Step 7: Determine if the iteration termination condition is met, i.e., whether the maximum number of iterations (MAX_FES) has been reached. If the iteration termination condition is met, output the coordinates and fitness values ​​of all dead cells and end the algorithm; otherwise, perform non-dominated sorting on the cell population, and sort the cells proportionally (num) according to their rank values. q ,nump ,num i Reclassify dormant cells, growing cells, and invading cells, and return to step 3.

[0231] 4. Calculation and processing module

[0232] This module, based on physical computing resources, executes computational tasks within the system. The hardware primarily consists of: the vehicle's own computing resources, edge servers deployed along the roadside, and servers in the cloud data center. The vehicle's own computing resources, including CPU and memory, are limited, as is its energy capacity, and each vehicle has different resource configurations. Due to these limitations, the vehicle's computing power is relatively weak, only able to handle tasks with low computational demands and low memory requirements. Edge servers, compared to vehicles, have more abundant computing resources, but their size is still relatively small and they exhibit heterogeneity, meaning they support different resource configurations. This computing architecture can provide flexible and sufficient computing resources for different types of tasks, meeting their computational needs. The cloud data center possesses even more abundant computing resources, capable of handling large-scale tasks exceeding the edge server's computing capacity. It can also serve as a backup resource to compensate for insufficient computing resources when the system is particularly busy, i.e., when tasks are concentrated and numerous.

[0233] After a task arrives at the corresponding compute node based on the unloading decision, a task queue is created, and tasks in the queue are processed according to a first-come, first-served (FCFS) strategy. The computing capabilities of each server are heterogeneous, and servers perform computations on a virtual machine basis. Figure 4 This is a task processing flowchart in the server. After tasks arrive at the server, they are queued according to their arrival order and executed sequentially on idle virtual machines. Therefore, the computing module provides different levels of computing services, including diverse computing efficiencies, rental prices, and power consumption, improving the system's versatility to cope with the diversity of user tasks.

[0234] 5. Environmental perception module

[0235] The hardware foundation of this module is the Roadside Unit (RSU), which includes an Edge Server (ES) for computation, a Micro Base Station (MIBS) for transmission, and sensors. The sensors are used to identify and acquire the vehicle's position and speed. Position is represented by two-dimensional coordinates, and speed is indicated by "+" and "-" signs to indicate the vehicle's direction of travel. This method is suitable for two-way, multi-lane scenarios. After the information is acquired, it is recorded in a JSON file, as shown in the following example:

[0236] {"Vid":99,"Location0":50,"Location1":4,"Speed":20000}

[0237] Wherein, "Vid" is the vehicle number, "Location0" and "Location1" refer to the vehicle's two-dimensional coordinates, "Location0" is the vehicle's horizontal coordinate on a straight road, and "Location1" is the vertical coordinate, with the initial value of the vertical coordinate being the side of the road where the roadside equipment is located. "Speed" is the vehicle speed (m / s), and on a two-way road, the positive and negative signs indicate the vehicle's direction of travel.

[0238] In addition to sensors collecting environmental parameters, edge servers and micro base stations have self-awareness capabilities; that is, when there are changes or malfunctions, they report the faults and update the currently available resource information. The vehicle parameters and environmental configuration information obtained by this module will be used for parameter settings of the multi-objective optimization model in the task unloading decision module.

[0239] 6. System Management Module

[0240] The system management module encapsulates the underlying modules into APIs, enabling users with different identities to access the system through visual operations and manage data and resources. For example... Figure 5 As shown, this module includes user information disclosure, user access for vehicle-side applications, access for computing service providers, and access for system administrators. Vehicle-side users can view and modify service requirements, including maximum task completion time and expected costs, and view the provider's historical service quality assessment, i.e., service reliability. Providers can view and modify resource configurations, including resource usage limits (i.e., lower limits for resource utilization and upper limits for server load), rental prices for various servers, view current resource usage, and set expected returns for adjustments and maintenance. System administrators can view the operation of optimization problem models and algorithms, facilitating fault detection and timely handling. The information disclosure module is open to authorized users such as patients and medical staff, allowing them to understand the system's usage, including user numbers, resource configuration, server prices, service evaluations, and user satisfaction. They can also provide feedback and opinions on the system, providing an information exchange and sharing platform for users and providers.

[0241] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.

Claims

1. A mobile medical oriented vehicle-to-everything computing service system, characterized in that, include: The task acquisition module is used to generate computational tasks from medical vehicles, statistically analyze the attributes of these tasks, and obtain task data to be processed and task attribute data. The task attribute data format is standardized. The environmental perception module is used to count the available resources in the computing service system, obtain computing resource status information, acquire network environment status information, perceive the location and speed of the medical vehicle, and obtain vehicle status information. The task offloading decision module establishes a multi-objective optimization problem model based on the interests of various stakeholders, including computing service users, providers, and public resource management. Utilizing a task offloading optimization algorithm, it obtains a task offloading strategy based on task attribute data, computing resource status, and vehicle status information. The optimization objectives include: average task completion time, total system energy consumption, average task overhead, and edge node load balancing. The task offloading decision module employs a multi-objective optimization algorithm to obtain a near-Pareto solution set. This multi-objective optimization algorithm refers to designing heuristic optimization algorithms based on multi-objective optimization problems, utilizing swarm intelligence algorithms, genetic algorithms, and combining multiple strategies to design an effective multi-objective task offloading optimization algorithm (MaOITG). O-TO solves the aforementioned multi-objective optimization problem. MaOITGO-TO, based on tumor cell growth patterns and considering the specificities of task unloading scenarios, incorporates multiple strategies. Utilizing tumor cell growth patterns, it searches the decision space in various ways, employing a Pareto optimal strategy to solve the optimization problem and obtain a near-Pareto solution set. MaOITGO-TO categorizes tumor cells into four types: dead cells, dormant cells, growing cells, and invading cells, designing different search methods for each cell type. Dead cells serve to store all non-dominated solutions, dormant cells undergo fine-grained searching, growing cells undergo coarse-grained searching, and invading cells undergo jump-style searching. Let the cell coordinates in MaOITGO-TO be... M represents the number of tasks, i.e., the dimension of the decision space. This represents the values ​​of the 1st, 2nd, ..., Mth dimensions of the cell coordinates, i.e., the execution node of the 1st, 2nd, ..., Mth task. MaOITGO-TO encoding encodes the execution node corresponding to local task execution as 0, and the execution node corresponding to task execution in the cloud data center as N+1, i.e., the number of edge nodes incremented by one. If the task is executed on an edge server, the encoding corresponds to the edge server number, i.e., 1 to N. Each cell coordinate corresponds to a point in the target space, i.e., the fitness value, whose structure is as follows: , representing the function values ​​of the average completion time, total energy consumption, load balancing, and average cost of the target task, respectively; The data transmission module, based on computing resource location and vehicle location information, and according to the task offloading strategy, utilizes V2I communication technology to realize the uploading and downloading of computing task data; The computing processing module provides computing resources to process arriving tasks. The facilities providing computing resources include: the vehicle itself, edge servers deployed on one side of the road, and cloud data centers in a remote location. The system management module is the external functional module of the computing service system. Through visual operation, it provides management capabilities for services, applications, and corresponding data and tasks, including user access, resource management, management of the interests of participating parties, information display, and access control.

2. The vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 1, characterized in that, The specific details of the task acquisition module are as follows: Medical vehicles generate a variety of computational tasks, including image analysis, image processing, data querying, case matching, case analysis, and medical history tracking. These tasks vary in size, computational load, and timeliness requirements. Local vehicles can handle some simple tasks with low computational load, while other tasks that cannot be handled by the current vehicle require remote processing. The process involves extracting the attributes of the tasks to be processed, including task size, computational load, required memory, maximum completion time, and the vehicle number to which the task belongs. The tasks are then numbered and the data is stored in a JSON-formatted configuration file. The data is stored in arrays, each array containing the aforementioned task attribute fields and values, separated by commas. The number of tasks is counted and recorded in the JSON file.

3. The vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 1, characterized in that, The specific details of the data transmission module are as follows: The hardware foundation of this module is the network link in the system. Tasks that need to be processed remotely are transmitted from vehicles to remote servers via V2I technology. Due to distance limitations, the vehicles generating tasks sometimes cannot communicate directly with the computing resources corresponding to the task offloading strategy. In such cases, transmission needs to be carried out through micro base stations or macro base stations. However, base station transmission also has distance limitations, and sometimes multiple base stations are required. Based on the vehicle location information and computing resource location information, combined with the network environment status, the most convenient and high-speed data transmission channel is constructed to realize data transmission.

4. The vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 1, characterized in that, The specific details of the task unloading decision module are as follows: The task offloading decision module is the core module of the computing service system. First, a multi-objective optimization problem model is established based on the interests of all parties involved, including users, service providers, and public resource management. Then, a near-Pareto solution set is obtained using a multi-objective optimization algorithm for task offloading. Finally, based on the actual situation, the final task offloading strategy is selected and sent to the data transmission module to guide each task to be transmitted to the target server and complete the offloading. The construction of the multi-objective optimization problem model refers to: establishing a function expression representing the value of the optimization objective function or the merits of the optimization objective, as well as function expressions representing various constraints existing in the task unloading process, based on the mathematical and logical relationships between the optimization objective, task parameters, and environmental parameters; considering the special nature of medical services, the task completion time must first be optimized to ensure timely completion; secondly, computational overhead must be optimized to reduce treatment costs and provide affordable medical services for ordinary patients; then, based on considerations of the commercial operation of medical services, the load balancing of edge servers must be optimized to reduce server maintenance costs and improve server lifespan; finally, given the massive scale of the computing service system, the high participation of patients and medical vehicles, and the extensive use and deployment of computing resources, high-performance computing consumes a large amount of energy, and the environmental protection issues related to carbon emissions cannot be ignored, requiring optimization of the total system energy consumption; to ensure the availability of the task unloading scheme, the optimization problem needs to be constrained by the following constraints: CPU, memory, and energy resource constraints on various computing nodes, maximum task completion time constraints, and edge node resource utilization constraints; Let the set of tasks in the computing service system be denoted as . The vehicle group is Edge servers, i.e., ES collections, are Where M, nv, and N represent the number of tasks, vehicles, and edge servers, respectively, and m, v, and e represent individual tasks, vehicles, and edge servers, respectively, with subscripts indicating their numbers; the communication facilities include micro base stations (MIBS) and macro base stations (MABS), with MIBS deployed together with ES and MABS deployed together with the cloud data center; the specific modeling of the above optimization problem is as follows: a. Average task completion time The goal is to minimize the average completion time of tasks. Tasks executed on different servers will have different completion times; i represents the task number. The completion time is expressed as: ； in, Representing tasks respectively The time it takes for the data to be transmitted from the vehicle to the target server is called the upload time, waiting time, execution time, and the time it takes for the calculation results to be returned to the vehicle is also called the return time. Indicates task Completion time; For tasks performed on local vehicles, the upload time, waiting time, and return time are as follows. Both are 0, therefore we have ; For tasks executed on edge servers, both upload and return times are calculated as the ratio of the task data volume to the corresponding network transmission rate; waiting time... Prediction using queuing theory; The specific calculation methods for upload time, execution time, and return time are as follows: ； ； ； in, and Representing tasks The amount of data to be uploaded and the amount of data to be returned. , and These represent the transmission rates from vehicle to MIBS, between MIBS, and from MIBS to vehicle, respectively. The transmission rates are calculated using Shannon's formula, and α and β represent the number of MIBSs required for the upload and download links, respectively. Indicates task The calculated density, Indicates assignment to task Computing resources; For tasks executed in cloud data centers, their upload time and return time are calculated based on their transmission path using the following methods: ； ； in, , These represent the transmission rates along the MIBS to MABS and MABS to MIBS transmission paths, respectively; therefore, the average task completion time is expressed as: ； Where delay is the average completion time of all tasks, and i is the task number; b. Average computational cost The overhead of remote computing services will be discussed in three cases: If the task is executed locally, the cost of each task is 0, meaning the task... The cost is Because local vehicles are exempt from charges; If a task is executed on an edge server, i.e., an edge node, the cost of each task is the execution time multiplied by the price per unit time on the server. The cost is ,in Indicates task Is it at the edge node? If executed, the value is 1; otherwise, the value is 0. It is an edge node The price, where j is the edge node number; If the task is executed on a cloud server, then the task The cost is ,in This is the price per unit of time for cloud servers; Therefore, the average computational cost of the task Represented as: ; c. Load balancing c1. Calculate the load on each edge node: edge nodes The total resources required for the uploading and unloading tasks are: ， ； in, Represents edge nodes CPU resources used Represents edge nodes The memory resources occupied by the device It is a task Required CPU resources It is a task Required memory resources; edge nodes The load is: , ； in, and Representing edge nodes respectively The sum of CPU and memory resources; and Representing edge nodes respectively CPU load and memory load; c2. Calculate the average load of edge nodes: , ； in, This represents the average load on CPU resources. This indicates the average load on memory resources; c3. Express the load balancing of computation nodes using variance: , ； in, and These represent the differences in CPU and memory load at edge nodes, respectively. Therefore, load balancing metrics for: To achieve a more balanced load, the load balancer (LB) needs to be minimized. d. Total energy consumption Based on the relationship between power and CPU frequency ,in These are power consumption, power factor, and CPU frequency; the relationship between energy consumption and power. ,in Based on energy consumption and working time, the following tasks are obtained. energy consumption The calculation formula is as follows: If the task is executed locally, then: ; If the task is executed at the edge, then: Among them, energy consumption is calculated. Transmission energy consumption , , , , and These represent the transmission power along the transmission paths from vehicle to MIBS, between MIBS, and from MIBS to vehicle. , These are the upload energy consumption and the return energy consumption, respectively. If the task is executed in a cloud data center, then: Among them, energy consumption is calculated. Transmission energy consumption , , , , These represent the transmission power along the MIBS to MABS and MABS to MIBS transmission paths, respectively. Therefore, the total energy consumption of the system for: ; e. Optimize problem modeling The optimization issues can be summarized as follows: ； St 1). ； 2). ； 3). ； 4). ； 5). ； 6). ； 7). ； 8). ； The four minimization formulas for the optimization problem represent: minimizing the average task completion time, minimizing the total system energy consumption, minimizing load balancing, and minimizing the average task computational cost. The constraints are as follows: Rule 1 states that the completion time of each task does not exceed the maximum completion time of the task; Rule 2 states that the local computing energy consumption of the vehicle does not exceed the vehicle's energy consumption; Rule 3 states that the CPU resources required for executing tasks on the vehicle do not exceed the vehicle's CPU computing power; Rule 4 states that the memory required for processing tasks by the vehicle does not exceed the vehicle's memory; Rule 5 states that the computational load of each edge server processing tasks does not exceed its own CPU resources; Rule 6 states that the memory usage of each edge server processing tasks does not exceed its own memory resources; Rule 7 states that the computational load of each edge server must be higher than the minimum load threshold; Rule 8 is a binary variable constraint. Representing tasks Is it on a local or edge node? Executed in cloud data centers; if so, the value is 1; otherwise, it is 0. This represents the maximum completion time threshold for the i-th task. , , These represent the available energy, available CPU, and available memory of the nth vehicle, respectively. , Representing edge nodes respectively Available CPU and memory This represents the minimum CPU load threshold for edge nodes.

5. A vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 4, characterized in that, The specific steps of MaOITGO-TO are described below: Step 1: Initialize the cell population, set the population size to pop_size, that is, the number of cells in the population is pop_size; initialize 4 types of cells, namely: determine the set of nodes with corresponding computing power according to the memory size required for task execution, and semi-randomize to generate four cell populations: all tasks are executed at the edge, tasks are executed at the edge and cloud, tasks are executed locally and at the edge, and tasks are executed locally, at the edge and cloud. Step 2: Calculate the rank of each cell using the non-dominated sorting algorithm, denoted by rank. Classify cells into dormant cells, growing cells, and invading cells according to their rank, with the following proportions: And add all currently non-dominated solutions to the dying cell; Step 3: Dormant cells perform fine-grained searches. Half of the dormant cells are guided forward by extreme points, which are the points where the minimum value is located on the four targets. The formulas for advancing speed and position update are as follows: ； ； in, These are the coordinates of the extreme point. This is the cell's current coordinates; It is the original coordinate of the i-th dimension of the cell. This is the new coordinate of the i-th dimension of the cell. Indicates the current moment. +1 indicates the next moment. This is the current speed. It is the updated speed, with each dimension of the cell calculated according to probability. Move forward or remain unchanged; The other half of the dormant cells move forward according to the optimized goal, and each dimension of the cell is determined by probability. The options are as follows: a. Minimize task completion time: Migrate the task to a cloud data center; b. Minimize total energy consumption: Migrate tasks on cloud data centers or high-power edge servers to low-power edge servers; c. Minimize load balancing: Migrate tasks on edge nodes with above-average load to edge nodes with below-average load; d. Minimize computational overhead: Migrate tasks from cloud data centers or expensive edge servers to cheaper edge servers or local vehicles; Step 4: The growing cell moves forward guided by the global optimum. There are two strategies for selecting the global optimum. One is to divide the non-dominated solutions into regions based on the distance from the non-dominated solution to the reference point, calculate the density of the non-dominated solutions, and select the non-dominated solution with the smallest density as the global optimum. The other is to use the roulette wheel method to select a non-dominated solution as the global optimum. The formulas for the rate and location update of growing cells are: ； ； in, and These represent the coordinates of two globally optimal points. , , It is a parameter. , It is a random number between 0 and 1; Step 5: The invading cell performs a crossover operation, employing two crossover strategies. One strategy involves the invading cell exchanging partial dimension values ​​with two global optima, namely: or Another approach is to randomly select one of the two global optima as the optimal point, and then simulate binary crossover between the invading cell and the optimal point. ； ； in, This represents the coordinate of the i-th dimension of the invading cell that needs to perform the crossover operation. This represents the coordinate of the i-th dimension of the optimal point. and Let i and n represent the coordinates of the invading cell currently performing the crossover operation and the global optimum in the i-th dimension, respectively. It is determined by the distribution factor The result is determined randomly according to the following formula. It is a custom parameter: ； Where rand is a random number between 0 and 1; Step 6: Perform non-dominated sorting on the newly generated cells, add dead cells to the non-dominated solutions, update the dead cells, and remove the dominated solutions; Step 7: Determine if the iteration termination condition is met, i.e., whether the maximum number of iterations (MAX_FES) has been reached; if the termination condition is met, output the coordinates and fitness values ​​of all dead cells and end the algorithm; otherwise, perform non-dominated sorting on the cell population, and sort the cells proportionally according to their rank values. Reclassify dormant cells, growing cells, and invading cells, and return to step 3.

6. A vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 1, characterized in that, The specific details of the computation processing module are as follows: Based on physical computing resources, the system executes computational tasks. The hardware includes the vehicle's own computing resources, roadside edge servers, and servers in a cloud data center. Tasks are transferred to computing nodes for processing according to a task offloading strategy. The vehicle itself, the roadside edge servers, and the remote cloud data center can all perform computational processing. Upon receiving a task, the computing node generates a task queue and processes tasks in the queue according to a first-come, first-served strategy. Each server has heterogeneous computing capabilities, with servers performing computations on a virtual machine basis. Therefore, the computing module provides different levels of computing services, including diverse computing efficiencies, rental prices, and power consumption, improving the system's versatility to handle diverse user tasks.

7. A vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 1, characterized in that, The specific details of the environmental perception module are as follows: The hardware foundation of this module is the Roadside Unit (RSU) located on one side of the road, which includes a Micro Base Station (MIBS) and an Edge Server (ES). The micro base station, in addition to data transmission, is used to sense network status and promptly report network faults or congestion information. The edge server, besides task processing, is used to sense computing resource information and promptly report resource fault information. Additionally, the roadside unit has a sensor to sense the position and speed of vehicles within its signal range, sending this information to the task offloading decision module as part of the parameters for the multi-objective optimization problem. When there are changes in network or computing resources, the change information is sent to the task offloading decision module, which modifies the parameters within the multi-objective optimization problem model accordingly. Vehicle position and speed, along with network status statistics, constitute environmental parameters, while computing resource status statistics constitute resource information.

8. A vehicle-to-everything (V2X) computing service system for mobile healthcare according to claim 1, characterized in that, The specific details of the system management module are as follows: Each underlying module is encapsulated into an API, enabling the system to be accessed by users with different identities through visual operations, allowing for data and resource management. This includes access for vehicle users, computing service providers, and system maintainers. Vehicle users can view and modify service requirements, including maximum task completion time, expected overhead, and expected task completion time, and view the provider's historical service quality assessment, i.e., service reliability. Computing service providers can view and modify resource configurations, including resource usage limits, i.e., minimum resource utilization and minimum server load, rental prices of various servers, adding or removing equipment, and viewing current resource usage for adjustments and maintenance. System maintainers can view the optimization problem model and algorithm execution status, facilitating problem identification and timely handling. Authorized medical staff and patients can view the system's usage, including publicly available information such as system coverage, number of connected vehicles, server prices, and service quality evaluations. This helps patients understand the system, builds their confidence in disease treatment, and ensures their rights through price transparency.

Images