Maintenance service platform and method based on automobile data collection

Abstract

The invention relates to the technical field of automobile maintenance data service platforms, in particular to a maintenance service platform and method based on automobile data collection, and the platform comprises a service request receiving unit, an automobile condition portrait generation unit, a service entity calling unit, a topological structure construction unit, a route discovery execution unit and a matching scheme determination unit. A vehicle state comprehensive portrait is generated and a qualified service entity is called by receiving a request including vehicle features and service types. And constructing a virtual service topology taking the service entity and the request as nodes, wherein the attribute of the edge is dynamically assigned by the elastic coefficient of the service entity and the urgency level of the request. And performing multi-level service routing discovery on the topology to form a group of service routing link sets connected with supply and demand nodes. And determining an execution sequence of the service matching scheme according to the link attribute configuration. According to the method, dynamic and accurate matching and path planning of the maintenance service based on the supply and demand real-time state are realized.

Description

Technical Field

[0001] This invention relates to the field of automotive repair data service platform technology, and in particular to a repair and maintenance service platform and method based on automotive data collection. Background Technology

[0002] Currently, automotive data-driven repair and maintenance service platforms generally rely on static or pre-defined rules for their service matching mechanisms. A common practice is for the platform to filter qualified service providers from its resource database based on the user's input of the vehicle model, fault description, or maintenance items. Matching and ranking are often based on static indicators such as the service provider's geographical location, historical user ratings, and fixed pricing, resulting in a list-style recommendation. This model essentially compares and ranks service requests against a static list of service providers.

[0003] The core flaw of existing technical solutions lies in their unidirectional and rigid matching logic. They fail to correlate the real-time service capacity elasticity of service providers with the specific context of user requests. While existing methods can handle routine and simple service needs, they cannot achieve optimal resource allocation when faced with sudden failures, complex maintenance tasks, or scenarios with extremely high timeliness requirements. Furthermore, existing technologies typically output one or several discrete alternative service providers, lacking the path planning capability to decompose a complex service request and have multiple service entities complete it through collaborative relay, thus limiting the platform's potential to handle complex service processes and optimize overall service efficiency.

[0004] There is a need for a technical solution that can deeply integrate the dynamic states of both supply and demand sides and upgrade the service matching process from "selection" to "path planning". This requires the platform to not only dynamically evaluate the service provider's responsiveness to specific urgent needs, but also to build a virtual service network and explore multiple possible service execution paths within this network, thereby achieving accurate and efficient matching for complex and dynamic service scenarios. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a maintenance and repair service platform and method based on vehicle data collection.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a maintenance and repair service platform based on vehicle data collection, comprising: The service request receiving unit is used to receive service initiation requests containing vehicle characteristic information and service type identifier; The vehicle condition profile generation unit is used to activate the pre-stored vehicle condition depth detection process based on the vehicle feature information in the service initiation request, and generate a comprehensive vehicle condition profile. The service entity invocation unit is used to invoke service entities that meet preset response qualifications from the service resource library based on the comprehensive vehicle status profile and the service type identifier. The topology construction unit is used to construct a virtual service topology with the service entity as the supply node and the service initiation request as the consumer node. The attribute values ​​of the edges in the virtual service topology are jointly assigned by the service elasticity coefficient of the service entity and the demand urgency level of the service initiation request. The routing discovery execution unit is used to perform multi-level service routing discovery operations based on the attribute values ​​of each path in the virtual service topology, forming a set of service routing links that associate the supply node and the consumer node. The matching scheme determination unit is used to determine the execution sequence of the service matching scheme based on the attribute values ​​of each link in the service routing link set.

[0007] Preferably, the step of activating a pre-stored vehicle condition depth detection process based on the vehicle feature information in the service request to generate a comprehensive vehicle status profile includes: The vehicle feature information is analyzed to extract the vehicle identification code and the set of real-time vehicle operating parameters; The vehicle identification code is compared with the historical maintenance record database to obtain a list of all service items and timestamp sequences for the vehicle. Anomaly pattern scanning is performed on the real-time vehicle operating parameter set to identify parameter items that deviate from the standard operating range and the magnitude of their deviation; By integrating the list of previous service items, the timestamp sequence, and the identified parameters that deviate from the standard operating range and their deviation magnitude, a multi-dimensional comprehensive vehicle status profile is constructed. The comprehensive vehicle status profile includes component health indicators, maintenance cycle offset, and potential risk feature vectors.

[0008] Preferably, the step of calling a service entity that meets the preset response qualifications from the service resource library includes: The potential risk feature vector and the service type identifier in the comprehensive vehicle status profile are input into a pre-configured service qualification filter; The service qualification filter matches a preset fault handling capability label with the potential risk feature vector and a preset service business scope label with the service type identifier. In the service resource library, all service entities that simultaneously possess the fault handling capability tag and the service business scope tag are retrieved in parallel. Calculate a dynamic response score for each retrieved service entity, which is based on the service entity's current task load rate, historical average service satisfaction rate, and geographical distance from the service request origination location. Service entities whose dynamic response scores are higher than the preset qualification threshold are marked as service entities that meet the preset response qualifications, and their information is added to the list of service entities to be scheduled.

[0009] Preferably, the calculation of the dynamic response score for each retrieved service entity includes: Obtain the real-time task queue length and historical average task processing rate of the service entity, and calculate the current task load rate of the service entity. The service entity retrieves all service completion records within a preset historical period from the service evaluation database, and performs a weighted average of the user satisfaction scores in each record to obtain the historical service satisfaction average, wherein the weight of recently completed records is higher than that of older completed records. The registered service address of the service entity and the coordinates of the location where the service request was initiated are obtained through the geolocation service interface, and the actual path distance between the two points is calculated as the geolocation distance. The current task load rate, the historical average service satisfaction rate, and the geographical distance are normalized respectively to obtain the corresponding load normalization value, satisfaction normalization value, and distance normalization value. The load normalization value, the satisfaction normalization value, and the distance normalization value are linearly combined according to a preset weight ratio to generate a dynamic response score for the service entity.

[0010] Preferably, the construction of the virtual service topology structure with the service entity as the supply node and the service initiation request as the consumer node includes: Each service entity that meets the preset response qualifications is instantiated as an independent supply node; Instantiate the service request as an independent consumer node; A directed virtual edge is established between each of the supply nodes and the consumer nodes, and the direction of the directed virtual edge is defined as from the supply node to the consumer node; Obtain the upper limit of service resources and the current occupied resource value of the service entity, and calculate the service elasticity coefficient of the service entity. Parse the user priority identifier and fault severity code contained in the service request and map them to the corresponding urgency level of the demand; Based on the service elasticity coefficient and the demand urgency level, each directed virtual edge is assigned an attribute value through a preset mapping table. The attribute value represents the feasibility and strength of the supply node providing services to the consumer node.

[0011] Preferably, the step of performing multi-level service route discovery operations based on the attribute values ​​of each path in the virtual service topology to form a set of service route links associated with the supply node and the consumer node includes: In the virtual service topology, a reverse path probing is initiated with the consumer node as the convergence target; The reverse path probe traverses all directed virtual edges pointing to the consumer node and reads the attribute values ​​on each directed virtual edge. For each directed virtual edge, its attribute value is used as the initial path weight, and backtracked to the corresponding supply node to form an initial service routing link; All initial service routing links formed are sorted according to their path weights, and a preset number of initial service routing links with the highest path weights are selected as core routing links. Based on the core routing link, attempts are made to combine multiple initial service routing links with lower path weights in parallel or in series to form a composite service routing link, and the overall path weight of the composite link is recalculated. All core routing links and composite service routing links whose path weights meet the preset routing strength threshold are aggregated to form a service routing link set.

[0012] Preferably, the step of determining the execution sequence of the service matching scheme based on the attribute values ​​of each link in the service routing link set includes: For each service routing link in the set of service routing links, analyze its composition and identify the attribute values ​​of the supply nodes and the virtual edges between the nodes. For each service routing link, the attribute values ​​of all virtual edges contained therein are aggregated to obtain the overall service strength index of the service routing link. All service routing links are sorted in descending order based on the overall service strength index to generate a priority queue of service routing links. The supply node combination corresponding to the service routing link ranked first in the priority queue is determined as the primary execution scheme in the service matching scheme. The supply nodes corresponding to the service routing links ranked later in the priority queue are combined and sequentially determined as alternative execution schemes in the service matching scheme, forming a sequence of alternative schemes according to their ranking.

[0013] Preferred options also include: Establish a continuous communication connection with the vehicle-mounted data acquisition terminal and receive the vehicle operating condition streaming data periodically reported by the vehicle-mounted data acquisition terminal; The vehicle operating condition streaming data is cleaned and structured in real time to generate a standard format vehicle operating status time sequence record. The vehicle operating status time sequence record is input into an early warning model trained based on a historical fault case library; The early warning model outputs a health degradation trend map and the estimated remaining effective lifespan for a specific vehicle subsystem or component. When the estimated remaining effective lifespan is lower than the set safety threshold, a proactive maintenance reminder is automatically generated, which includes suggested inspection items and suggested maintenance times.

[0014] Preferably, the step of inputting the vehicle operating status time-series record into an early warning model trained based on a historical fault case library includes: A large number of vehicle operation data sequences before and after known faults were extracted from the historical fault case library as training samples; For each training sample, label its corresponding fault type, fault location, and effective warning time window before the fault occurs; The training samples are used to supervise the training of the machine learning model, enabling the machine learning model to learn to identify feature patterns that match the precursors of various faults from the input vehicle operation status time series records. After training, the machine learning model is solidified into the early warning model, which is used to process the time-series records of newly input vehicle operating status in real time.

[0015] Preferably, the present invention also includes a maintenance and repair service method based on vehicle data collection, the method comprising all the modules and method flow of the maintenance and repair service platform based on vehicle data collection as described above.

[0016] Compared with the prior art, the advantages and positive effects of the present invention are as follows: By constructing a virtual service topology structure where edge attributes are jointly assigned by the service resilience coefficient of service entities and the urgency level of the requester's demand, the matching decision-making basis shifts from static, isolated service provider attributes to a dynamic, interconnected supply-demand relationship network state. The service resilience coefficient quantifies a service entity's ability to adjust its resource allocation to respond to uncertain demands, while the demand urgency level characterizes the strength of the timeliness constraint of the current request. The combined calculation of these two factors ensures that each connection in the network reflects in real time the actual adaptability of a specific supply to a specific demand and its potential response cost. This allows the platform to transcend fixed sorting rules and instantly generate a dynamically updated service relationship network with weighted parameters each time a request is initiated, providing a dynamic model that accurately characterizes the current supply-demand situation for matching decisions.

[0017] By performing multi-level service routing discovery operations on a dynamically weighted virtual service topology, the platform's service matching output evolves from a discrete list of candidate service providers into a set of service routing links associated with supply and consumer nodes. This process simulates the mechanism of finding multiple feasible paths in a data communication network. The discovered routing links can be simple paths directly to a single service entity, or composite paths composed of multiple service entities working sequentially or in parallel. The output link set means that the platform can provide multiple potential service fulfillment solutions for a single request, each potentially corresponding to different costs, durations, resource combinations, and collaboration modes. This empowers the platform to plan complex service processes, decompose and orchestrate service tasks, and optimize service resource scheduling and load balancing at the global level, enabling flexible and refined service provisioning models. Attached Figure Description

[0018] Figure 1 This is a timing diagram of the maintenance and repair service platform based on vehicle data collection described in this invention; Figure 2 Flowchart of the vehicle condition profile generation unit's operation; Figure 3 A flowchart for multi-level service routing discovery operations; Figure 4 A comparison chart of service intensity for different aggregation methods in an automotive repair and maintenance service platform; Figure 5 A radar chart showing the health status of various vehicle systems. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] See Figure 1 The specific implementation of the maintenance and repair service platform based on vehicle data collection is as follows: The platform receives a service initiation request containing vehicle feature information and service type identifier. Based on the vehicle feature information in the service initiation request, it activates a pre-stored vehicle condition depth detection process to generate a comprehensive vehicle status profile. According to the comprehensive vehicle status profile and service type identifier, it calls service entities that meet the preset response qualifications from the service resource library. It constructs a virtual service topology structure with service entities as supply nodes and service initiation requests as consumer nodes. The attribute values ​​of the edges in the virtual service topology structure are jointly assigned by the service elasticity coefficient of the service entity and the demand urgency level of the service initiation request. According to the attribute values ​​of each path in the virtual service topology structure, it performs a multi-level service routing discovery operation to form a set of service routing links that associate supply nodes and consumer nodes. Based on the attribute values ​​of each link in the service routing link set, it determines the execution sequence of the service matching scheme.

[0022] In one embodiment of the present invention, see [reference] Figure 2The vehicle maintenance service platform, based on vehicle data collection, receives a service request. The request includes vehicle characteristic information (license plate number A12345, engine speed fluctuation data, transmission oil temperature data) and a service type identifier ("emergency fault repair"). The vehicle condition profile generation unit parses the vehicle characteristic information, extracting the vehicle identification code "A12345" and the vehicle's real-time operating parameters ("{engine speed: 850-1200 rpm (fluctuation), transmission oil temperature: 105℃}"). The vehicle condition profile generation unit compares the vehicle identification code "A12345" with the historical maintenance record database to obtain a list of past service items ("{June 1, 2025: oil change; December 1, 2025: air filter replacement}") and a timestamp sequence ("{2025-06-01, 2025-12-01}"). The vehicle condition profile generation unit scans the real-time operating parameters of the vehicle for abnormal patterns, identifying the parameter "transmission oil temperature" and its deviation of "+15℃" that deviates from the standard operating range. The standard operating range is "90℃". The vehicle condition profile generation unit integrates the service item list, timestamp sequence, and the identified parameters that deviate from the standard operating range and their deviations to construct a multi-dimensional comprehensive vehicle condition profile. The comprehensive vehicle condition profile includes the component health index "transmission health: low", the maintenance cycle offset "45 days since last maintenance", and the potential risk feature vector "{risk component: transmission; risk type: overheating; risk level: high}".

[0023] In practical implementation, the service entity invocation unit inputs the potential risk feature vector "{risk component: transmission; risk type: overheating; risk level: high}" from the vehicle status comprehensive profile and the service type identifier "emergency fault repair" into a pre-configured service qualification filter. The service qualification filter matches the potential risk feature vector with the preset fault handling capability tag "transmission repair" and the service type identifier with the preset service business scope tag "emergency repair." It then searches the service resource library in parallel for all service entities that simultaneously possess both the fault handling capability tag "transmission repair" and the service business scope tag "emergency repair." The service entity invocation unit calculates a dynamic response score for each retrieved service entity, based on the service entity's current task load rate, historical average service satisfaction, and geographical distance from the service request origination point. The service entity invocation unit marks service entities whose dynamic response scores are higher than the preset qualification threshold as service entities that meet the preset response qualifications. For example, "Entity A" has a score of 85 and "Entity B" has a score of 72. The preset qualification threshold is 70. Therefore, "Entity A" and "Entity B" are marked as service entities that meet the preset response qualifications, and their information is added to the list of service entities to be scheduled.

[0024] It's understandable that calculating the dynamic response score for each retrieved service entity involves multiple quantitative indicators. The process involves obtaining the service entity's real-time task queue length and historical average task processing rate to calculate its current task load rate. For example, if "Entity A" has a current task queue length of 3 and a historical average task processing rate of 2 orders / hour, its current task load rate is calculated to be 1.5. All service completion records for the service entity within a preset historical period are retrieved from the service evaluation database, and the user satisfaction score in each record is weighted and averaged to obtain the historical service satisfaction average, with recently completed records having a higher weight than older records. The registered service address and the coordinates of the service request's originating location are obtained through the geolocation service interface, and the actual path distance between the two points is calculated as the geolocation distance. For example, "Entity A" is 5 kilometers from the request originating location. The current task load rate, historical service satisfaction average, and geolocation distance are then normalized to obtain the corresponding load normalization value, satisfaction normalization value, and distance normalization value.

[0025] Optionally, the service qualification screening strategy for different service types can be adjusted. The service qualification screener matches preset fault handling capability tags based on potential risk feature vectors. For example, if the potential risk feature vector contains "risk component: battery", then the fault handling capability tag "electrical system repair" is matched. The service qualification screener matches preset service business scope tags based on service type identifiers. For example, if the service type identifier is "periodic maintenance", then the service business scope tag "routine maintenance" is matched. All service entities that simultaneously possess matching fault handling capability tags and service business scope tags are retrieved in parallel from the service resource library. A dynamic response score is calculated for each retrieved service entity. The dynamic response score is calculated based on the service entity's current task load rate, historical average service satisfaction, and geographical distance from the service request originating from. Service entities with dynamic response scores higher than a preset qualification threshold are marked as service entities that meet the preset response qualifications, and their information is added to the list of service entities to be scheduled.

[0026] In some embodiments, the dimensions for constructing a comprehensive vehicle status profile can be expanded. Vehicle feature information is parsed to extract the vehicle identification code and a set of real-time vehicle operating parameters. This set of parameters may include brake pad wear sensor data and tire pressure monitoring data. The vehicle identification code is compared with a historical maintenance record database to obtain a list of past service items and a timestamp sequence. This list includes items such as brake pad replacement and four-wheel alignment. Anomaly pattern scanning is performed on the real-time vehicle operating parameter set to identify parameters deviating from the standard operating range and their deviation magnitudes; for example, identifying brake pad thickness data below the standard safety threshold. The list of past service items, the timestamp sequence, and the identified parameters deviating from the standard operating range and their deviation magnitudes are integrated to construct a multi-dimensional comprehensive vehicle status profile. This profile includes component health indicators such as "brake system health," maintenance cycle offsets, and potential risk feature vectors such as "{risk component: brake pad; risk type: excessive wear}".

[0027] Optionally, data retrieval and computation during service entity invocation can be performed in parallel. All service entities possessing both fault handling capability and service business scope tags are retrieved in parallel from the service resource repository. The parallel retrieval process simultaneously launches multiple query threads to access different partitions of the database. A dynamic response score is calculated for each retrieved service entity. The calculation process for the dynamic response score involves launching an independent computation thread for each service entity, while simultaneously acquiring the current task load rate, historical average service satisfaction rate, and geographical distance. Service entities with dynamic response scores higher than a preset eligibility threshold are marked as meeting the preset response eligibility criteria. This marking operation is performed uniformly after the dynamic response scores of all entities have been calculated, and their information is added to the list of service entities to be scheduled.

[0028] It is understandable that the potential risk feature vector in the comprehensive vehicle status profile directly affects the selection of service entities. The service qualification filter receives the potential risk feature vector from the comprehensive vehicle status profile, which indicates that "potential risks are concentrated in the power battery pack." The service qualification filter matches the preset fault handling capability tag "New Energy Vehicle High Voltage System Repair" based on the potential risk feature vector. The service qualification filter receives the service type identifier "Diagnostic Inspection" and matches the preset service business scope tag "System Diagnosis" based on the service type identifier. It searches the service resource library in parallel for all service entities that simultaneously possess both the fault handling capability tag "New Energy Vehicle High Voltage System Repair" and the service business scope tag "System Diagnosis." It calculates a dynamic response score for each retrieved service entity, based on the service entity's current task load rate, historical average service satisfaction, and geographical distance from the service request origination point. Service entities with dynamic response scores higher than the preset qualification threshold are marked as meeting the preset response qualification and their information is added to the list of service entities to be scheduled.

[0029] In one embodiment of the present invention, see [reference] Figure 3 The service entity invocation unit obtains the real-time task queue length and historical average task processing rate of the service entity, and calculates the current task load rate of the service entity. For example, for a service entity named "Entity A", its real-time task queue length is 4 orders, and its historical average task processing rate is 3 orders per hour. The service entity invocation unit calculates the current task load rate of the service entity as 1.33 by division. The service entity invocation unit retrieves all service completion records of the service entity within a preset historical period from the service evaluation database, and performs a weighted average of the user satisfaction scores in each record to obtain the historical service satisfaction average, where the weight of recent completion records is higher than that of older completion records. For example, retrieving 10 service completion records of "Entity A" in the past 30 days, the weight of the most recent 3 records is set to 0.6, and the weight of the remaining 7 historical records is set to 0.4. The weighted average of the user satisfaction scores (out of 5) in these 10 records is calculated to obtain the historical service satisfaction average of 4.65. The service entity calling unit obtains the registered service address of the service entity and the coordinates of the location where the service request was initiated through the geolocation service interface, and calculates the actual path distance between the two points as the geolocation distance.

[0030] In some embodiments, the normalization process converts indicators with different dimensions to the same scale. The current task load rate is normalized to obtain a corresponding load normalization value. For example, if the system sets the maximum load rate baseline to 5, the load normalization value is calculated as the current task load rate of 1.33 divided by 5, resulting in 0.266. The historical service satisfaction average is normalized to obtain a corresponding satisfaction normalization value. For example, if the historical service satisfaction average is 4.65 points divided by the maximum score of 5, the satisfaction normalization value is 0.93. The geographical distance is normalized to obtain a corresponding distance normalization value. For example, if the system sets the maximum service radius to 20 kilometers, the distance normalization value is calculated as the geographical distance of 8 kilometers divided by 20 kilometers, resulting in a distance normalization value of 0.4. The service entity invocation unit linearly combines the load normalization value, satisfaction normalization value, and distance normalization value according to a preset weight ratio to generate a dynamic response score for the service entity.

[0031] It can be understood that the generation of dynamic response scores is achieved through a mathematical formula. This formula is expressed as:

[0032] in: This represents the final dynamic response score. This represents the preset weighting coefficients assigned to the load factor. This represents the load normalization value after normalization. This represents the preset weighting coefficients assigned to the satisfaction factor. This represents the normalized satisfaction value after normalization. This represents the preset weighting coefficient assigned to the distance factor. This represents the normalized distance value after normalization. Substituting the numerical value, let... , , ,but After conversion to a percentage scale, the dynamic response score is 80.52.

[0033] Optionally, the weighted averaging strategy for historical service satisfaction can be implemented in different ways. All service completion records of the service entity within a preset historical period are retrieved from the service evaluation database. The preset historical period can be the past 90 days. When weighting the user satisfaction score in each record, different weighting factors are assigned according to the chronological order of the records. For example, records from the most recent 10 days have a weight of 0.7, records from day 11 to day 30 have a weight of 0.2, and records from day 31 to day 90 have a weight of 0.1. When calculating the historical service satisfaction average, the user satisfaction score of each record is multiplied by its corresponding weighting factor, summed, and then divided by the sum of all weighting factors. Coordinates are obtained through the geolocation service interface, and the actual path distance is calculated. The calculation process may consider real-time traffic information, and the estimated travel distance is taken as the geolocation distance. The current task load rate, historical service satisfaction average, and geolocation distance are normalized respectively to obtain the corresponding load normalization value, satisfaction normalization value, and distance normalization value. The load normalization value, satisfaction normalization value, and distance normalization value are linearly combined according to a preset weight ratio to generate a dynamic response score for the service entity.

[0034] In the specific implementation, the dynamic response score of another service entity, "Entity B," was calculated to demonstrate the data comparison. The service entity invocation unit obtained the real-time task queue length of service entity "Entity B" as 8 orders, and the historical average task processing rate as 2 orders per hour, calculating the current task load rate of the service entity as 4.0. The service entity invocation unit retrieved the service completion records of service entity "Entity B" within a preset historical period from the service evaluation database, and calculated the historical average service satisfaction score as 4.0 using the same weighting strategy. The service entity invocation unit calculated the actual path distance between service entity "Entity B" and the coordinates of the service request initiation location as 2 kilometers through the geolocation service interface. The current task load rate of 4.0 was normalized, with the load normalization value of 4.0 divided by the system's maximum load rate benchmark of 5, resulting in 0.8. The historical average service satisfaction score of 4.0 was normalized, with the satisfaction normalization value of 4.0 divided by 5, resulting in 0.8. The geolocation distance of 2 kilometers was normalized, with the distance normalization value of 2 divided by the maximum service radius of 20 kilometers, resulting in 0.1. The same formula was used. With weighting coefficients ( , , Perform the calculation: After conversion to a percentage system, the dynamic response score is 64.0.

[0035] In some embodiments, different measurement methods can be used to calculate geographic distance. The latitude and longitude coordinates of the registered service address of the service entity and the latitude and longitude coordinates of the location where the service request was initiated are obtained through the geographic location service interface. The actual path distance between two points can be calculated without using the straight-line distance; instead, the driving distance based on the actual road network can be obtained by calling the map application programming interface, and this driving distance is used as the geographic distance. The service entity calling unit normalizes the current task load rate, the historical average service satisfaction rate, and the geographic distance based on the road network. During normalization, a maximum service response distance threshold is set for the geographic distance based on the road network, and the actual obtained driving distance is divided by this threshold to obtain the distance normalization value. The load normalization value, satisfaction normalization value, and distance normalization value are linearly combined according to a preset weight ratio to generate a dynamic response score for the service entity.

[0036] Optionally, the current task load rate can be calculated based on more granular data. Obtain the real-time task queue length of the service entity, which includes the number of ongoing service orders and the number of scheduled but not yet started service orders. Obtain the historical average task processing rate of the service entity, calculated based on the number of service orders completed daily over the past week. When calculating the current task load rate of the service entity, divide the real-time task queue length by the product of the historical average task processing rate and a standard working time. Normalize the current task load rate, historical average service satisfaction rate, and geographical distance to obtain corresponding load normalization values, satisfaction normalization values, and distance normalization values. Linearly combine the load normalization value, satisfaction normalization value, and distance normalization value according to a preset weight ratio to generate a dynamic response score for the service entity.

[0037] In one embodiment of the present invention, the maintenance and repair service platform based on vehicle data collection constructs a virtual service topology in the topology construction unit, with service entities as supply nodes and service initiation requests as consumer nodes. The topology construction unit instantiates each service entity that meets preset response qualifications as an independent supply node; for example, service entity "Entity A" is marked as supply node N1, and service entity "Entity B" is marked as supply node N2. The topology construction unit instantiates a service initiation request as an independent consumer node, for example, marked as consumer node C1. The topology construction unit establishes a directed virtual edge between each supply node and consumer node, where the direction of the directed virtual edge is defined as from the supply node to the consumer node; that is, a directed virtual edge E_{N1->C1} is established between supply node N1 and consumer node C1, and a directed virtual edge E_{N2->C1} is established between supply node N2 and consumer node C1. The topology construction unit obtains the service resource ceiling value and the currently occupied resource value of the service entity, and calculates the service elasticity coefficient of the service entity. For example, the service resource ceiling value of service entity "Entity A" is 10 (meaning it can process 10 orders at the same time), and the currently occupied resource value is 7, so the calculated service elasticity coefficient is (10-7) / 10=0.3. The topology construction unit parses the user priority identifier and fault severity code contained in the service initiation request and maps them to the corresponding demand urgency level. For example, if the parsed user priority identifier is "VIP member" and the fault severity code is "S2", the demand urgency level is mapped to "high" by querying the preset mapping rule table. Based on the service elasticity coefficient and demand urgency level, the topology construction unit assigns an attribute value to each directed virtual edge through the preset mapping relationship table. The attribute value represents the feasibility and strength of the supply node providing services to the consumer node. For example, the mapping relationship table stipulates that when the demand urgency level is "high" and the service elasticity coefficient is in the range (0.2, 0.4], the attribute value is assigned to 5. Therefore, the directed virtual edge E_{N1->C1} obtains the attribute value 5.

[0038] It's understandable that the service elasticity coefficient can be calculated based on different resource models. The service entity's service resource ceiling value is obtained, which can refer to the maximum number of work orders the service entity can simultaneously handle, the total technician hours, or the number of dedicated equipment. The service entity's currently occupied resource value is obtained, reflecting the corresponding resource consumption of work orders currently committed to or being executed by the service entity. The service elasticity coefficient of the service entity is calculated using a subtraction and division operation, expressed by the following formula:

[0039] in: This represents the calculated service elasticity coefficient. The upper limit of service resources for a service entity. This represents the current resource usage of the service entity. It parses the user priority identifier and fault severity code contained in the service request. The user priority identifier may be "Regular User" or "Gold Member," and the fault severity code may be "S1" (Minor) or "S3" (Severe). Based on the service elasticity coefficient and demand urgency level, it assigns an attribute value to each directed virtual edge through a pre-defined mapping table.

[0040] In some embodiments, the mapping rules for demand urgency levels can be more refined. The user priority identifier contained in the service request is parsed; this identifier originates from user account profile data. The fault severity code contained in the service request is also parsed; this code is generated by the vehicle profile generation unit based on potential risk feature vectors in the comprehensive vehicle status profile. When mapping to the corresponding demand urgency level, a two-dimensional lookup table is used, with the user priority identifier and fault severity code as the joint input key, outputting a quantified demand urgency level value, for example, a value ranging from 1 to 10. Based on the service elasticity coefficient and demand urgency level, a preset mapping relationship table is used. This table can be a two-dimensional matrix, where the row index represents a discrete demand urgency level range, the column index represents a discrete service elasticity coefficient range, and the values ​​within the matrix cells are attribute values. The topology construction unit assigns an attribute value to each directed virtual edge.

[0041] Optionally, the establishment and attribute assignment of directed virtual edges can be performed in batches. Each service entity that meets the preset response qualifications is instantiated as an independent supply node, with a unique node identifier assigned to each service entity during the instantiation process. The service initiation request is instantiated as an independent consumer node, and a consumer node identifier is assigned. A directed virtual edge is established between each supply node and consumer node, and the operation records include the supply node identifier, consumer node identifier, and edge direction. The service resource limit and currently occupied resource value of the service entity are obtained from the real-time status database of the service entity. The service elasticity coefficient of the service entity is calculated. The user priority identifier and fault severity code contained in the service initiation request are parsed and mapped to the corresponding demand urgency level. Based on the service elasticity coefficient and demand urgency level, an attribute value is assigned to each directed virtual edge through a preset mapping table.

[0042] In the specific implementation, a virtual service topology involving another service entity, "Entity C," was constructed to demonstrate the data comparison. The topology construction unit instantiated the service entity "Entity C" as an independent supply node N3. The topology construction unit established a directed virtual edge E_{N3->C1} between the supply node N3 and the consumer node C1. The topology construction unit obtained the service resource limit value of the service entity "Entity C" as 8, the currently occupied resource value as 1, and calculated the service elasticity coefficient as (8-1) / 8=0.875. The topology construction unit parsed the same service initiation request, the user priority identifier was "ordinary user", the fault severity code was "S1", and by querying the same preset mapping rule table, the demand urgency level was mapped to "low". Based on the service elasticity coefficient of 0.875 and the demand urgency level of "low", the topology construction unit used the preset mapping relationship table, which stipulates that when the demand urgency level is "low" and the service elasticity coefficient is greater than 0.8, the attribute value is assigned as 2. Therefore, the directed virtual edge E_{N3->C1} is assigned the attribute value 2. This attribute value contrasts with attribute value 5 of the directed virtual edge E_{N1->C1}, reflecting the difference in service feasibility strength between different supply nodes for the same consumer node.

[0043] In some embodiments, the definition of the service resource ceiling value can be multidimensional. The service resource ceiling value of the service entity is obtained. This ceiling value is not a single numerical value, but a vector containing multiple dimensions such as "technician working hours ceiling," "lifting machine position ceiling," and "diagnostic equipment ceiling." The currently occupied resource value of the service entity is also obtained; this value is also a vector corresponding to the corresponding dimension. When calculating the service elasticity coefficient of the service entity, it is necessary to aggregate the multidimensional resources, for example, taking the minimum or weighted average of the remaining resource proportions of each dimension as the comprehensive service elasticity coefficient. Based on the service elasticity coefficient and the demand urgency level, an attribute value is assigned to each directed virtual edge through a preset mapping table.

[0044] Optionally, the instantiation of consumer nodes can be compatible with complex request scenarios. A service request is instantiated as an independent consumer node. When a single service request contains multiple parallel sub-service requirements, it can be instantiated as a consumer node group with an internal substructure, including a main consumer node and multiple virtual sub-consumer nodes. Directed virtual edges are established between each supply node and the relevant sub-consumer nodes in the consumer node group. Based on the service elasticity coefficient and demand urgency level calculated or evaluated for each sub-service requirement, attribute values ​​are assigned to each directed virtual edge through a pre-defined mapping table.

[0045] In one embodiment of the present invention, the maintenance service platform based on vehicle data collection performs multi-level service route discovery operations in the route discovery execution unit according to the attribute values ​​of each path in the virtual service topology. The virtual service topology includes supply node N1, supply node N2, supply node N3 and consumer node C1. Referring to Table 1, the directed virtual edges between the supply nodes and the consumer nodes and their attribute values ​​are shown.

[0046] Table 1: Attribute Values ​​of Directed Virtual Edges

[0047] The routing discovery execution unit initiates reverse path probing in the virtual service topology with consumer node C1 as the convergence target. The reverse path probing traverses all directed virtual edges pointing to consumer node C1 and reads the attribute values ​​on each directed virtual edge. For each directed virtual edge, its attribute value is used as the initial path weight to backtrack to the corresponding supply node to form an initial service routing link. For example, traversing directed virtual edge N1->C1 forms initial service routing link L1 (path weight 8), traversing directed virtual edge N2->C1 forms initial service routing link L2 (path weight 6), and traversing directed virtual edge N3->C1 forms initial service routing link L3 (path weight 4). The routing discovery execution unit sorts all the formed initial service routing links according to their path weights. The sorting results are L1 (8), L2 (6), and L3 (4). The routing discovery execution unit selects the initial service routing links with the highest path weights in a preset number as core routing links. The preset number is set to 2, so the core routing links are L1 and L2. The route discovery execution unit, based on the core routing link, attempts to combine multiple initial service routing links with lower path weights in parallel or series to form composite service routing links and recalculates the overall path weight of the composite links. For example, it attempts to combine the initial service routing link L3 with the core routing link L1 in parallel to form the composite service routing link L_comb1. This parallel combination means that both the supply node N1 and the supply node N3 serve the consumer node C1, and the overall path weight needs to be recalculated. The overall path weight calculation of the composite service routing link uses an aggregation function, expressed by the formula:

[0048] in: This represents the overall path weight of the composite service routing link. This represents the attribute value of each directed virtual edge contained in the composite service routing link. This represents the number of directed virtual edges contained in a composite service routing link. This represents a preset harmonic coefficient used to balance the influence of the minimum and average values. For the composite service routing link L_comb1, which includes directed virtual edges N1->C1 (attribute value 8) and N3->C1 (attribute value 4), let... ,but The route discovery execution unit aggregates all core routing links and composite service routing links whose path weights meet the preset route strength threshold to form a service routing link set. The preset route strength threshold is set to 5, so the service routing link set includes L1 (8), L2 (6) and L_comb1 (7).

[0049] In some embodiments, the traversal process of reverse path probing can be filtered based on attribute values. The routing discovery execution unit initiates reverse path probing in the virtual service topology with the consumer node as the convergence target. Reverse path probing traverses all directed virtual edges pointing to the consumer node, but only reads edges with attribute values ​​higher than a certain probing threshold, for example, only reading directed virtual edges with attribute values ​​greater than 5. For each directed virtual edge that meets the condition, its attribute value is used as the initial path weight to backtrack to the corresponding supply node to form an initial service routing link. The routing discovery execution unit sorts all formed initial service routing links according to their path weights and selects a preset number of initial service routing links with the highest path weights as core routing links. Based on the core routing links, the routing discovery execution unit attempts to combine multiple initial service routing links with lower path weights in parallel or in series to form composite service routing links and recalculates the overall path weight of the composite links. The routing discovery execution unit summarizes all core routing links and composite service routing links whose path weights meet a preset routing strength threshold to form a service routing link set.

[0050] In specific implementation, the matching scheme determination unit determines the execution sequence of the service matching scheme based on the attribute values ​​of each link in the service routing link set. The matching scheme determination unit analyzes the composition of each service routing link in the service routing link set, identifies the supply nodes and the attribute values ​​of the virtual edges between the nodes, for example, analyzing service routing link L1 identifies supply node N1 and attribute value 8, analyzing service routing link L_comb1 identifies supply nodes N1, supply node N3 and attribute values ​​8 and 4. For each service routing link, the matching scheme determination unit aggregates the attribute values ​​of all virtual edges it contains to obtain the overall service strength index of the service routing link. The aggregation operation adopts the summation method. For example, the overall service strength index of service routing link L1 is 8, the overall service strength index of service routing link L2 is 6, and the overall service strength index of service routing link L_comb1 is 8+4=12. The matching scheme determination unit sorts all service routing links in descending order according to the overall service strength index to generate a priority queue of service routing links. The descending order result is L_comb1(12), L1(8), L2(6). The matching scheme determination unit determines the supply node combination corresponding to the service routing link ranked first in the priority queue as the primary execution scheme in the service matching scheme, that is, the primary execution scheme is the combination of supply node N1 and supply node N3. The matching scheme determination unit then determines the supply node combinations corresponding to the subsequent ranked service routing links in the priority queue as the alternative execution schemes in the service matching scheme, forming a sequence of alternative schemes in order of ranking. In the sequence of alternative schemes, the first alternative is supply node N1 (corresponding to L1), and the second alternative is supply node N2 (corresponding to L2).

[0051] Optionally, different mathematical methods can be used to aggregate the overall service strength index. For each service routing link, the matching scheme determination unit aggregates the attribute values ​​of all virtual edges it contains. The aggregation operation can be to calculate the geometric mean of the attribute values ​​or to take the maximum value among the attribute values. The matching scheme determination unit sorts all service routing links in descending order according to the overall service strength index to generate a priority queue of service routing links. The matching scheme determination unit determines the supply node combination corresponding to the service routing link ranked first in the priority queue as the primary execution scheme in the service matching scheme. The matching scheme determination unit sequentially determines the supply node combinations corresponding to the service routing links ranked subsequently in the priority queue as alternative execution schemes in the service matching scheme, forming a sequence of alternative schemes according to their ranking.

[0052] In some embodiments, the combination of service routing links may include a concatenated form. The routing discovery execution unit attempts to combine multiple initial service routing links with lower path weights into a composite service routing link based on the core routing link. Concatenation means that the service flow sequentially passes through multiple supply nodes and finally to the service consumption node; for example, supply node N1 processes part of the task and then passes the remaining task to supply node N3. The routing discovery execution unit recalculates the overall path weight after concatenation. The overall path weight calculation for the concatenated composite service routing link may take the minimum value or product of the path weights of each segment. The routing discovery execution unit aggregates all core routing links and composite service routing links whose path weights meet a preset routing strength threshold to form a service routing link set. The matching scheme determination unit analyzes the composition of each service routing link in the service routing link set, identifying the supply nodes and the attribute values ​​of the virtual edges between nodes. For each service routing link, the matching scheme determination unit aggregates the attribute values ​​of all virtual edges it contains to obtain the overall service strength index of the service routing link. The matching scheme determination unit sorts all service routing links in descending order according to the overall service strength index to generate a priority queue for the service routing links. The matching scheme determination unit identifies the supply node combination corresponding to the service routing link ranked first in the priority queue as the primary execution scheme in the service matching scheme. The matching scheme determination unit then sequentially identifies the supply node combinations corresponding to the subsequent ranked service routing links in the priority queue as alternative execution schemes in the service matching scheme, forming a sequence of alternative schemes according to their ranking.

[0053] It is understandable that the resource pre-allocation process can be triggered once the execution sequence of the service matching scheme is determined. The matching scheme determination unit identifies the supply node combination corresponding to the service routing link ranked first in the priority queue as the primary execution scheme in the service matching scheme. After the primary execution scheme is determined, the platform sends service reservation requests to supply nodes N1 and N3. The matching scheme determination unit then sequentially identifies the supply node combinations corresponding to the subsequent ranked service routing links in the priority queue as alternative execution schemes in the service matching scheme, forming a sequence of alternative schemes according to their ranking. This sequence of alternative schemes is used to activate the next alternative scheme when a supply node in the primary execution scheme is confirmed to be unable to provide service.

[0054] See Figure 4This is a comparison chart of service intensity using different aggregation methods in an automotive repair and maintenance service platform. The aggregation method selection helps the platform choose a more reasonable service intensity calculation method; the clear link priority judgment shows that L_comb1 has the optimal service intensity, providing a quantitative basis for selecting the "primary execution plan"; the strength of single-node links (L1, L2) is stable and can serve as a core evaluation indicator for alternative plans. It intuitively shows that the service intensity of the composite link (L_comb1) is significantly higher than that of the single-node links (L1, L2), providing data support for "prioritizing multi-node parallel links as the primary execution plan"; by comparing different aggregation results, it verifies the rationality that "summation aggregation better reflects the collaborative value of multiple nodes," providing a basis for system algorithm iteration.

[0055] In one embodiment of the present invention, a maintenance service platform based on vehicle data collection establishes a continuous communication connection with an onboard data acquisition terminal, receiving periodically reported vehicle operating condition streaming data from the onboard data acquisition terminal. For example, the platform receives streaming data packets reported every 10 seconds from the onboard data acquisition terminal of a vehicle with license plate number "B6789". The data packets contain readings from multiple sensors such as engine speed, coolant temperature, oil pressure, and battery voltage. The platform performs real-time cleaning and structured transformation on the vehicle operating condition streaming data, generating a standard format vehicle operating status time-series record. The cleaning process includes filtering outliers exceeding physical range, filling in missing values ​​caused by brief signal loss, and converting the unstructured raw data stream into a standard record arranged by timestamp, parameter name, and parameter value structure. The platform inputs the vehicle operating status time-series record into an early warning model trained based on a historical fault case library. The early warning model outputs a health degradation trend map and estimated remaining effective lifespan for specific vehicle subsystems or components. When the estimated remaining effective lifespan is lower than the set safety threshold, the platform automatically generates a proactive maintenance reminder that includes suggested inspection items and suggested maintenance times.

[0056] The training process of the early warning model relies on historical fault data. A large number of vehicle operation data sequences before and after known faults are extracted from a historical fault case database as training samples. For example, 1000 data sequences of coolant temperature and engine load from the seven days prior to a "water pump failure" are extracted as a set of training samples. For each training sample, its corresponding fault type, fault location, and effective warning time window before the fault are labeled. The training samples are used to supervise the training of the machine learning model, enabling it to learn to identify feature patterns matching the precursors of various faults from the input vehicle operation status time-series records. After training, the machine learning model is solidified into an early warning model for real-time processing of newly input vehicle operation status time-series records.

[0057] In some embodiments, the generation of vehicle operating status time-series records involves multi-source data fusion. The platform receives periodically reported vehicle operating condition streaming data from the onboard data acquisition terminal. This streaming data may originate from the vehicle controller area network bus, onboard diagnostic interface, and additional smart sensors. The platform performs real-time cleaning and structure transformation on the vehicle operating condition streaming data. Cleaning rules include removing instantaneous spike interference and performing time-aligned interpolation on data with different sampling frequencies to generate vehicle operating status time-series records in a standard format. The standard format ensures consistent timestamps, parameter encoding, and numerical units. The platform inputs the vehicle operating status time-series records into an early warning model trained based on a historical fault case library. The early warning model outputs a health degradation trend map and estimated remaining effective lifespan for specific vehicle subsystems or components. When the estimated remaining effective lifespan is lower than a set safety threshold, the platform automatically generates a proactive maintenance reminder including suggested inspection items and suggested maintenance times.

[0058] In practical implementation, the braking system is used as an example to demonstrate the data flow and early warning generation process. The platform receives periodically reported vehicle operating condition streaming data from the onboard data acquisition terminal. This streaming data includes wheel speed sensor signals, brake pedal travel sensor signals, and brake pad wear indicator resistance values. The platform performs real-time cleaning and structured transformation on the vehicle operating condition streaming data to generate a standard format vehicle operating status time-series record. The platform inputs this vehicle operating status time-series record into an early warning model trained based on a historical fault case library. The early warning model outputs a "left front brake pad health degradation trend graph" and "estimated remaining effective lifespan: 1500 kilometers". When the estimated remaining effective lifespan is lower than the set safety threshold, the platform automatically generates a proactive maintenance reminder. The safety threshold is set at 2000 kilometers. Since 1500 kilometers is lower than 2000 kilometers, the platform generates a reminder: "Recommended inspection item: left front brake pad; recommended maintenance time: within the next 500 kilometers or within two weeks".

[0059] Optionally, the early warning model can output a quantified health score, calculated based on feature deviation. The early warning model identifies feature patterns matching various precursory symptoms from the input vehicle operating status time-series records and quantifies the degree of matching. The early warning model outputs a health degradation trend map and estimated remaining effective lifespan for a specific vehicle subsystem or component. The estimated remaining effective lifespan may be calculated based on a decay function, with the following form:

[0060] in: This represents the calculated estimated remaining effective lifespan. This represents the baseline lifespan of the component in its brand-new condition. This represents an attenuation coefficient that is related to the component material and working intensity. This represents the cumulative damage or characteristic deviation calculated by the early warning model based on the time-series records of the current vehicle operating status.

[0061] In some embodiments, the generation of proactive maintenance reminders can be associated with a service type identifier. When the estimated remaining effective lifespan is lower than a set safety threshold, the platform automatically generates a proactive maintenance reminder containing suggested inspection items and suggested maintenance times. The proactive maintenance reminder itself can be encapsulated as a service initiation request with a "preventive maintenance" service type identifier. The platform inputs vehicle operating status time-series records into an early warning model trained based on a historical fault case library. The early warning model outputs a health degradation trend map and estimated remaining effective lifespan for a specific vehicle subsystem or component. The proactive maintenance reminders automatically generated by the platform include a suggested maintenance time window calculated based on the estimated remaining effective lifespan and the time required for maintenance operations.

[0062] It is understandable that the training sample annotation for the historical fault case database requires precise temporal correlation. A large number of vehicle operation data sequences before and after known faults are extracted from the historical fault case database as training samples. During extraction, it is necessary to ensure that the time window of the data sequence accurately covers the effective warning period before the fault occurs. For each training sample, its corresponding fault type, fault location, and effective warning time window before the fault are labeled. The effective warning time window is determined by working backwards from the fault occurrence time in the maintenance record and the timestamp of the data sequence. The training samples are used to supervise the training of the machine learning model, enabling the model to learn to identify feature patterns matching the warning signs of various faults from the input vehicle operation status time-series records. After training, the machine learning model is solidified into an early warning model for real-time processing of newly input vehicle operation status time-series records.

[0063] See Figure 5 This is a radar chart showing the health status of various vehicle systems. It visually presents the health weaknesses of each system (such as the braking system), providing precise direction for maintenance and repair. For systems with low scores (such as the braking system), it can trigger inspection / maintenance suggestions in advance to prevent malfunctions. Combined with the vehicle's health status, it assists the maintenance platform in matching corresponding service resources (such as specialized braking system inspections). By condensing the health status of multiple vehicle systems into an intuitive radar chart, it quickly grasps the overall health level of the vehicle, avoiding the one-sidedness of assessments based on single indicators. Based on the differences in health scores among various systems, it prioritizes the repair of low-scoring systems, improving the efficiency of maintenance resource utilization. It accurately identifies weak systems, providing clear targets for preventative maintenance and reducing the risk of malfunctions.

[0064] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A maintenance and repair service platform based on vehicle data collection, characterized in that, The platform includes: The service request receiving unit is used to receive service initiation requests containing vehicle characteristic information and service type identifier; The vehicle condition profile generation unit is used to activate the pre-stored vehicle condition depth detection process based on the vehicle feature information in the service initiation request, and generate a comprehensive vehicle condition profile. The service entity invocation unit is used to invoke service entities that meet preset response qualifications from the service resource library based on the comprehensive vehicle status profile and the service type identifier. The topology construction unit is used to construct a virtual service topology with the service entity as the supply node and the service initiation request as the consumer node. The attribute values ​​of the edges in the virtual service topology are jointly assigned by the service elasticity coefficient of the service entity and the demand urgency level of the service initiation request. The routing discovery execution unit is used to perform multi-level service routing discovery operations based on the attribute values ​​of each path in the virtual service topology, forming a set of service routing links that associate the supply node and the consumer node. The matching scheme determination unit is used to determine the execution sequence of the service matching scheme based on the attribute values ​​of each link in the service routing link set.

2. The maintenance and repair service platform based on vehicle data collection according to claim 1, characterized in that, The process of activating a pre-stored vehicle condition depth detection process based on the vehicle feature information in the service request to generate a comprehensive vehicle status profile includes: The vehicle feature information is analyzed to extract the vehicle identification code and the set of real-time vehicle operating parameters; The vehicle identification code is compared with the historical maintenance record database to obtain a list of all service items and timestamp sequences for the vehicle. Anomaly pattern scanning is performed on the real-time vehicle operating parameter set to identify parameter items that deviate from the standard operating range and the magnitude of their deviation; By integrating the list of previous service items, the timestamp sequence, and the identified parameters that deviate from the standard operating range and their deviation magnitude, a multi-dimensional comprehensive vehicle status profile is constructed. The comprehensive vehicle status profile includes component health indicators, maintenance cycle offset, and potential risk feature vectors.

3. The maintenance and repair service platform based on vehicle data collection according to claim 2, characterized in that, The step of calling a service entity that meets the preset response qualifications from the service resource repository includes: The potential risk feature vector and the service type identifier in the comprehensive vehicle status profile are input into a pre-configured service qualification filter; The service qualification filter matches a preset fault handling capability label with the potential risk feature vector and a preset service business scope label with the service type identifier. In the service resource library, all service entities that simultaneously possess the fault handling capability tag and the service business scope tag are retrieved in parallel. Calculate a dynamic response score for each retrieved service entity, which is based on the service entity's current task load rate, historical average service satisfaction rate, and geographical distance from the service request origination location. Service entities whose dynamic response scores are higher than the preset qualification threshold are marked as service entities that meet the preset response qualifications, and their information is added to the list of service entities to be scheduled.

4. The maintenance and repair service platform based on vehicle data collection according to claim 3, characterized in that, The calculation of the dynamic response score for each retrieved service entity includes: Obtain the real-time task queue length and historical average task processing rate of the service entity, and calculate the current task load rate of the service entity. The service entity retrieves all service completion records within a preset historical period from the service evaluation database, and performs a weighted average of the user satisfaction scores in each record to obtain the historical service satisfaction average, wherein the weight of recently completed records is higher than that of older completed records. The registered service address of the service entity and the coordinates of the location where the service request was initiated are obtained through the geolocation service interface, and the actual path distance between the two points is calculated as the geolocation distance. The current task load rate, the historical average service satisfaction rate, and the geographical distance are normalized respectively to obtain the corresponding load normalization value, satisfaction normalization value, and distance normalization value. The load normalization value, the satisfaction normalization value, and the distance normalization value are linearly combined according to a preset weight ratio to generate a dynamic response score for the service entity.

5. The maintenance and repair service platform based on vehicle data collection according to claim 1, characterized in that, The construction of the virtual service topology structure, with the service entity as the supply node and the service initiation request as the consumer node, includes: Each service entity that meets the preset response qualifications is instantiated as an independent supply node; Instantiate the service request as an independent consumer node; A directed virtual edge is established between each of the supply nodes and the consumer nodes, and the direction of the directed virtual edge is defined as from the supply node to the consumer node; Obtain the upper limit of service resources and the current occupied resource value of the service entity, and calculate the service elasticity coefficient of the service entity. Parse the user priority identifier and fault severity code contained in the service request and map them to the corresponding urgency level of the demand; Based on the service elasticity coefficient and the demand urgency level, each directed virtual edge is assigned an attribute value through a preset mapping table. The attribute value represents the feasibility and strength of the supply node providing services to the consumer node.

6. The maintenance and repair service platform based on vehicle data collection according to claim 5, characterized in that, The step involves performing a multi-level service route discovery operation based on the attribute values ​​of each path in the virtual service topology to form a set of service route links associated with the supply node and the consumer node, including: In the virtual service topology, a reverse path probing is initiated with the consumer node as the convergence target; The reverse path probe traverses all directed virtual edges pointing to the consumer node and reads the attribute values ​​on each directed virtual edge. For each directed virtual edge, its attribute value is used as the initial path weight, and backtracked to the corresponding supply node to form an initial service routing link; All initial service routing links formed are sorted according to their path weights, and a preset number of initial service routing links with the highest path weights are selected as core routing links. Based on the core routing link, attempts are made to combine multiple initial service routing links with lower path weights in parallel or in series to form a composite service routing link, and the overall path weight of the composite link is recalculated. All core routing links and composite service routing links whose path weights meet the preset routing strength threshold are aggregated to form a service routing link set.

7. The maintenance and repair service platform based on vehicle data collection according to claim 6, characterized in that, The step of determining the execution sequence of the service matching scheme based on the attribute values ​​of each link in the service routing link set includes: For each service routing link in the set of service routing links, analyze its composition and identify the attribute values ​​of the supply nodes and the virtual edges between the nodes. For each service routing link, the attribute values ​​of all virtual edges contained therein are aggregated to obtain the overall service strength index of the service routing link. All service routing links are sorted in descending order based on the overall service strength index to generate a priority queue of service routing links. The supply node combination corresponding to the service routing link ranked first in the priority queue is determined as the primary execution scheme in the service matching scheme. The supply nodes corresponding to the service routing links ranked later in the priority queue are combined and sequentially determined as alternative execution schemes in the service matching scheme, forming a sequence of alternative schemes according to their ranking.

8. The maintenance and repair service platform based on vehicle data collection according to claim 1, characterized in that, Also includes: Establish a continuous communication connection with the vehicle-mounted data acquisition terminal and receive the vehicle operating condition streaming data periodically reported by the vehicle-mounted data acquisition terminal; The vehicle operating condition streaming data is cleaned and structured in real time to generate a standard format vehicle operating status time sequence record. The vehicle operating status time sequence record is input into an early warning model trained based on a historical fault case library; The early warning model outputs a health degradation trend map and the estimated remaining effective lifespan for a specific vehicle subsystem or component. When the estimated remaining effective lifespan is lower than the set safety threshold, a proactive maintenance reminder is automatically generated, which includes suggested inspection items and suggested maintenance times.

9. The maintenance and repair service platform based on vehicle data collection according to claim 8, characterized in that, The step of inputting the vehicle operating status time-series records into an early warning model trained based on a historical fault case library includes: A large number of vehicle operation data sequences before and after known faults were extracted from the historical fault case library as training samples; For each training sample, label its corresponding fault type, fault location, and effective warning time window before the fault occurs; The training samples are used to supervise the training of the machine learning model, enabling the machine learning model to learn to identify feature patterns that match the precursors of various faults from the input vehicle operation status time series records. After training, the machine learning model is solidified into the early warning model, which is used to process the time-series records of newly input vehicle operating status in real time.

10. A maintenance and repair service method based on vehicle data collection, characterized in that, It includes all modules and method flows of the maintenance and repair service platform based on vehicle data collection as described in any one of claims 1 to 9.

Images