Vehicle state real-time monitoring and scheduling method and system based on multi-platform cooperation

Abstract

The application provides a multi-platform cooperative vehicle state real-time monitoring and scheduling method and system, and belongs to the technical field of monitoring and scheduling, and specifically comprises the following steps: determining the deviation condition of the vehicle state between platforms by using a synchronous monitoring and identification method, determining a dynamic updating method of an upper-shelf management and control platform in the platform based on the deviation condition, updating the upper-shelf management and control platform by using the dynamic updating method, determining an upper-shelf management and control method of the upper-shelf management and control platform by using the upper-shelf management and control platform data and the historical deviation data of the vehicle state between the upper-shelf management and control platform and other platforms, performing upper-shelf management and control processing of the vehicle of the upper-shelf management and control platform by using the upper-shelf management and control method, and determining a real-time monitoring and scheduling platform in the platform according to the upper-shelf limit data of different vehicles in different platforms, so that the abnormal risk of the synchronous state of the rental vehicle in the multi-platform is reduced.

Description

Technical Field

[0001] This invention belongs to the field of monitoring and scheduling technology, and in particular relates to a method and system for real-time monitoring and scheduling of vehicle status based on multi-platform collaboration. Background Technology

[0002] For car rental companies, rental information is often uploaded to multiple platforms. Therefore, if the scheduling and dispatching of cars across multiple platforms cannot be coordinated, there is a high probability of over-renting, which will affect the user's rental experience to some extent.

[0003] To address the aforementioned technical issues, the invention patent application CN202510113361.5, "Multi-platform Fusion Interaction Method and System Based on Touchscreen Large Screen," establishes a real-time data synchronization mechanism between platforms. This mechanism transmits data through a bidirectional data channel and dynamically adjusts the transmission strategy to ensure data consistency across platforms, thereby achieving efficient multi-platform fusion interaction, improving user experience, and reducing system latency. However, it suffers from the following drawbacks: When listing rental vehicles on multiple platforms, inconsistencies often arise in the status of the same rental vehicle across different platforms. Therefore, if a listing control strategy cannot be determined based on these inconsistencies between platforms, resulting in inconsistencies in the rental vehicles listed on platforms with higher synchronization risks, this becomes a pressing technical problem that needs to be solved.

[0004] Therefore, there is an urgent need for a real-time vehicle status monitoring and scheduling method and system based on multi-platform collaboration. Summary of the Invention

[0005] To achieve the objectives of this invention, the following technical solution is adopted: Specifically, this application provides a method for real-time monitoring and scheduling of vehicle status based on multi-platform collaboration, which includes: S1 uses rental vehicle data from various platforms as a basis to determine the correlation between rental vehicles on different platforms, determines a synchronous monitoring and identification method for the vehicle status of rental vehicles on different platforms based on the correlation, uses the synchronous monitoring and identification method to determine the deviation of vehicle status between platforms, and determines a dynamic update method for the listing management platform on the platform based on the deviation. S2 uses the dynamic update method to update the on-the-shelf management platform, and uses the on-the-shelf management platform data and the historical deviation data of vehicle status between the on-the-shelf management platform and other platforms to determine the on-the-shelf management method of the on-the-shelf management platform. S3 uses the aforementioned listing control method to manage the listing of vehicles on the listing control platform, and determines the real-time monitoring and scheduling platform on the platform based on the listing restriction data of different vehicles on different platforms.

[0006] The beneficial effects of this invention are as follows: Based on the data from the vehicle listing management platform and the historical deviation data of vehicle status between the platform and other platforms, the listing management method for the platform is determined. The specific management execution scope and strategy are "tailor-made" for each platform, that is, how to handle the avoidance of rental vehicles listed with other platforms. In order to ensure that the core risks are effectively controlled, the impact of platform management on the number of rental vehicles listed on the platform is minimized, and rental revenue is guaranteed.

[0007] Based on the listing restrictions of different vehicles on different platforms, a real-time monitoring and scheduling platform is determined. Given the existing listing mutual exclusion policy (prohibiting vehicles from being listed simultaneously on platforms with mutual risks), a dynamic "real-time monitoring and scheduling platform" designation mechanism is established to evaluate the effectiveness of the source restrictions and provide data-driven decision-making for the safe relaxation of restrictions and restoration of vehicle listing freedom in the future. Its core logic is "assessing the breadth of restrictions, monitoring changes in conflicts, and seizing opportunities for precise deregulation." By quantitatively analyzing the overall impact of listing mutual exclusion rules on vehicle cross-platform exposure, it is determined whether high-cost real-time monitoring needs to be initiated, thereby achieving the goal of "minimizing long-term business constraints on vehicle rentability and platform traffic caused by listing mutual exclusion while ensuring the fundamental objective of data consistency."

[0008] Furthermore, the rental vehicle data includes rental vehicles from different platforms.

[0009] Furthermore, the association of the rental vehicles is determined based on the data of the same rental vehicle being listed repeatedly on different platforms.

[0010] Furthermore, the method for determining the synchronous monitoring and identification method for the vehicle status of the rental vehicle is as follows: Based on the association between rental vehicles on different platforms, determine the platform on which the rental vehicle is listed, and use the platform on which the rental vehicle is listed as the listing platform for the rental vehicle; Based on the data from the listing platforms, determine the number of rental vehicles listed on the platforms; A synchronous monitoring and identification method for determining the vehicle status of rental vehicles based on the number of rental vehicles listed on different platforms.

[0011] Furthermore, the method for determining the real-time monitoring and scheduling platform in the platform is as follows: Based on the listing restrictions of different vehicles on different platforms, determine the number of platforms on which the vehicle will be listed. The vehicle's listing restriction coefficient is determined based on the proportion of the number of platforms on which the vehicle is listed to all platforms. Based on the vehicle listing data on different platforms, the number of vehicles listed on different platforms is determined, and combined with the vehicle listing restriction coefficient, the real-time monitoring and scheduling platform on the platform is determined.

[0012] It should be noted that if a platform is not subject to listing control as required by the listing control method in the above steps, then all vehicles will be listed, and the platform that handles the listing of all vehicles will be considered the full listing platform.

[0013] Secondly, the present invention provides a computer system comprising: a memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the above-described multi-platform collaborative vehicle status real-time monitoring and scheduling method when running the computer program.

[0014] Other features and advantages will be set forth in the following description, and the objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0015] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] The above and other features and advantages of the present invention will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0017] Figure 1 This is a flowchart of a multi-platform collaborative real-time vehicle status monitoring and scheduling method; Figure 2 This is a flowchart illustrating the method for determining the synchronous monitoring and identification of the vehicle status of rental vehicles. Figure 3 This is a flowchart illustrating the method for determining the dynamic update mechanism of the platform's listing management system. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] Example 1 like Figure 1 As shown, this application provides a real-time vehicle status monitoring and scheduling method based on multi-platform collaboration, specifically including: S1 uses rental vehicle data from various platforms as a basis to determine the correlation between rental vehicles on different platforms, determines a synchronous monitoring and identification method for the vehicle status of rental vehicles on different platforms based on the correlation, uses the synchronous monitoring and identification method to determine the deviation of vehicle status between platforms, and determines a dynamic update method for the listing management platform on the platform based on the deviation. S2 uses the dynamic update method to update the on-the-shelf management platform, and uses the on-the-shelf management platform data and the historical deviation data of vehicle status between the on-the-shelf management platform and other platforms to determine the on-the-shelf management method of the on-the-shelf management platform. S3 uses the aforementioned listing control method to manage the listing of vehicles on the listing control platform, and determines the real-time monitoring and scheduling platform on the platform based on the listing processing data of different vehicles on different platforms.

[0020] Furthermore, the rental vehicle data includes rental vehicles from different platforms.

[0021] Furthermore, the association of the rental vehicles is determined based on the data of the same rental vehicle being listed repeatedly on different platforms.

[0022] Specifically, such as Figure 2 As shown, the method for determining the synchronous monitoring and identification method for the vehicle status of the rental vehicle is as follows: The fundamental goal of this method is to design a mechanism that can intelligently assess the urgency of data synchronization and adaptively select monitoring trigger strategies in business scenarios where rental vehicles typically operate across multiple online platforms (≥5). This aims to maximize system resource utilization efficiency while ensuring the consistency of critical data. Its core logic is to "infer the global impact of micro-level vehicle status changes by macroscopically statistically analyzing the platform distribution characteristics of the vehicle pool, thereby matching a synchronization strategy of appropriate granularity." That is, if the vehicle pool as a whole exhibits a high degree of cross-platform overlap, it means that any change in vehicle status may trigger widespread data inconsistency risks, requiring highly sensitive synchronization (reliable identification methods). Conversely, if the vehicle pool as a whole is distributed across multiple platforms and operates independently, the impact of status changes is naturally limited, allowing for low-sensitivity batch synchronization (general identification methods), thus achieving a delicate balance between operational risk and system cost.

[0023] S11 determines the platform on which the rental vehicle is listed based on the association between rental vehicles on different platforms, and uses the platform on which the rental vehicle is listed as the listing platform for the rental vehicle. "Listing platform" refers to the online channel endpoint through which a vehicle publishes rental information and generates transaction orders. A vehicle can exist on one or more platforms simultaneously, forming a "one vehicle, multiple platforms" business model.

[0024] This is the data foundation of the entire analysis. In a complex multi-platform ecosystem, the need to synchronize vehicle status stems entirely from the potential information conflicts caused by the vehicle's "avatar" across multiple platforms. Accurately and dynamically maintaining each vehicle's "platform account" is the basis for assessing the potential impact radius of its status changes and calculating various macro-indicators.

[0025] Specific examples: After data cleaning and correlation, the vehicle listing status was determined as follows: V1 is listed only on P1; V2 is listed on P1 and P3; V3 is listed on all five platforms (P1 to P5); V4 is listed on P2, P4, and P5; V5 is listed on P3 and P5; V6 is listed only on P4.

[0026] S12 determines the number of rental vehicles listed on the platform based on the platform data; The number of platforms listed is a direct metric that reflects the breadth of coverage and channel complexity of a vehicle's online business.

[0027] This step transforms the qualitative platform list into sortable and aggregateable quantitative data, a crucial shift from micro to macro analysis. A larger number of platforms means more data outlets needing to maintain consistency in the vehicle's status information, and typically higher requirements for the timeliness of status updates and management value. This simple integer sequence serves as the core input vector for subsequently constructing a statistical profile of the entire vehicle pool.

[0028] Specific example (continuous): According to S11, the number of platforms in V1 is 1; V2 is 2; V3 is 5; V4 is 3; V5 is 2; V6 is 1. The resulting sequence is: {1, 2, 5, 3, 2, 1}.

[0029] S13 is a synchronous monitoring and identification method for determining the vehicle status of rental vehicles based on the number of rental vehicles listed on different platforms.

[0030] By comprehensively analyzing the statistical distribution characteristics of the number of vehicles "on the platform" in the vehicle pool, a decision is made on which global status synchronization monitoring triggering method to adopt.

[0031] The "Synchronous Monitoring and Identification Method" defines the decision rules for the system to trigger cross-platform status verification and update operations. The core consists of two modes: a reliable identification method (event-driven) – synchronous identification is performed after accumulating the first number of change events; and a general identification method (batch-driven) – unified synchronous identification is performed after accumulating the second number of change events.

[0032] In complex environments with numerous platforms (≥5), system processing power is a scarce resource. A holistic perspective is essential, and resource allocation strategies must be determined based on the overall composition of the vehicle pool. If vehicles are widely distributed across various platforms, high costs must be invested to ensure real-time synchronization and mitigate the risk of widespread overselling. If vehicles are primarily bound to specific platforms, low-cost batch synchronization can be employed, concentrating resources on more critical areas. This step represents a leap from "single-point-oriented" to "holistic" intelligent decision-making.

[0033] For example: Based on the sequence {1, 2, 5, 3, 2, 1}, we will make a decision through the following sub-steps.

[0034] It is understandable that the synchronous monitoring and identification method for determining the vehicle status of rental vehicles based on the number of rental vehicles listed on different platforms specifically includes: S131 determines the proportion of rental vehicles listed on all platforms based on the number of different rental vehicle listing platforms, and uses this as the full listing proportion. It then determines whether the full listing proportion is greater than a preset listing proportion threshold. If so, the synchronous monitoring and identification method for the vehicle status of the rental vehicles is determined to be a reliable identification method. That is, when the number of vehicles whose rental status changes is greater than a first preset number threshold, synchronous monitoring and identification processing is performed. If not, proceed to step S132. In the above steps, the proportion of vehicles listed on all platforms (P1-P5) (i.e., vehicles on platforms equal to the total number of platforms, which is 5) is calculated to represent the total number of vehicles, which is the full listing proportion.

[0035] The "full listing ratio" reflects the concentration of the "core omnichannel vehicles" in the vehicle pool, which have the highest requirements for strong data consistency and are the most complex to manage.

[0036] This is the most rigorous test. If this percentage is very high (e.g., exceeding 30%), it means that the "central nervous system" of the vehicle pool is highly developed, and every state change of a large number of vehicles will inevitably affect all platforms. In this case, adopting an "event-driven" synchronous processing strategy is a reasonable choice, because any delay will cause data chaos to the greatest extent, and its business risks far outweigh the computational costs. This is a top-level strategy based on worst-case prevention.

[0037] Specific example (continuous): Among V1-V6, only V3 is a "full-platform vehicle" (quantity = 5). Therefore, the total listing ratio = 1 / 6 ≈ 16.7%. Assuming the preset listing ratio threshold is 30%, since 16.7% < 30%, the condition is not met, proceeding to S132.

[0038] S132 determines the listing overlap coefficient based on the ratio of the average number of different rental vehicles listed on the platform to the number of platforms, and determines whether the listing overlap coefficient is greater than the preset overlap coefficient threshold. If yes, proceed to step S133. If no, determine that the synchronous monitoring and identification method for the rental vehicle status is a general identification method, that is, when the number of vehicles with rental status changes is greater than the preset number threshold, synchronous monitoring and identification processing is performed. Calculate the average number of vehicles listed on all platforms, then divide by the total number of platforms (5) to obtain the listing overlap coefficient. Formula: (Average number of listings on platforms) / (Total number of platforms).

[0039] The "listing overlap coefficient" is a macro-level indicator normalized to the [0, 1] range, quantifying the average tightness of business interweaving among vehicle pools across multiple platforms. The higher the coefficient, the more prevalent the inventory overlap between platforms and the stronger the data network correlation.

[0040] In scenarios with a large number of platforms (≥5), even if there aren't many "omnichannel" vehicles, as long as vehicles are generally listed on two, three, or more platforms (i.e., the average overlap is not low), the data coupling of the entire ecosystem remains very high. The probability of a single state change event causing a "ripple effect" and affecting multiple platforms is still considerable. When this coefficient exceeds the threshold, it means that batch synchronization may lead to inconsistent states persisting in the complex network for a long time, with uncontrollable risks, thus requiring further refined identification (S133).

[0041] It is understandable that the first preset quantity threshold is less than the preset quantity threshold.

[0042] Specific example (continuous): The average number of vehicle platforms is (1+2+5+3+2+1) / 6 = 14 / 6 ≈ 2.33. The total number of platforms is 5. The overlap coefficient = 2.33 / 5 = 0.466. Assuming the preset overlap coefficient threshold is 0.5, since 0.466 < 0.5, the condition is not met. Therefore, the system determines to use the "general identification method": that is, it does not require a single state change to immediately trigger synchronization, but only performs batch synchronization monitoring and identification processing when the cumulative number of vehicles with state changes reaches a preset threshold (such as 3 vehicles).

[0043] S133 defines rental vehicles whose number on the platform is less than a preset platform number threshold as independent vehicles, and determines whether the proportion of the independent vehicles in the rental vehicles is greater than a preset proportion threshold. If so, the synchronous monitoring and identification method for the vehicle status of the rental vehicles is determined to be a general identification method, that is, when the number of vehicles whose rental status has changed is greater than a preset number threshold, synchronous monitoring and identification processing is performed. If not, the synchronous monitoring and identification method for the vehicle status of the rental vehicles is determined to be a reliable identification method, that is, when the number of vehicles whose rental status has changed is greater than a first preset number threshold, synchronous monitoring and identification processing is performed.

[0044] This step is performed only when the overall overlap coefficient is high (>0.5) and is used to make the final decision on whether to use real-time or batch synchronization. Vehicles with a very small number of listings on the platform (e.g., less than a preset value of 2) are defined as independent vehicles, and their proportion is calculated.

[0045] "Independent vehicles" refer to vehicles with highly vertical business operations, typically belonging to only one or two specific platforms. "Independent vehicle percentage" reveals the degree of modularity or fragmentation in the business composition of the vehicle pool.

[0046] This is a mechanism to identify "false high overlap." Even if the average overlap coefficient is high, it may be due to a two-polar structure of "a small number of omnichannel vehicles + a large number of independent vehicles." If "independent vehicles" constitute the absolute majority (e.g., >60%), it indicates that the business is essentially operating in segments, and the overall risk is isolated. In this case, using a "batch-driven" strategy for the majority of independent vehicles is cost-effective, while the few omnichannel vehicles can be handled separately. Conversely, if independent vehicles are not dominant, it indicates that cross-platform operation is common, and a highly reliable approach should be adopted: when the number of vehicles with changing rental status exceeds a first preset threshold (e.g., 1), synchronous monitoring and identification should be implemented. This reflects refined cost control based on the actual business structure.

[0047] Specific example (assuming condition S132 is met): Assume the overlap coefficient is calculated to be 0.52 (>0.5), proceed to this step. Let the preset platform number threshold be 2; then vehicles with less than 2 platforms (V1 and V6) are considered independent vehicles. The percentage of independent vehicles = 2 / 6 ≈ 33.3%. Assume the preset percentage threshold is 60%. Since 33.3% < 60%, independent vehicles do not constitute the absolute majority. Therefore, the system ultimately determines to use the "reliable identification method".

[0048] This embodiment of the "Synchronous Monitoring and Identification Method" can accurately perceive the macro-level distribution pattern of the vehicle pool across multiple platforms (omni-channel core type, tightly intertwined type, and decentralized independent type) in complex business environments with a large number of platforms (≥5), and automatically route to the most suitable synchronization strategy (real-time or batch). This enables the system to dynamically adapt to the differentiated ecosystem structures of different cities, different vehicle models, or different stages of cooperation with minimal operating costs, exhibiting strong scalability and robustness.

[0049] Through a decision funnel composed of three levels of quantitative indicators (full listing ratio, listing overlap coefficient, and independent vehicle ratio), the system can proactively invest resources to ensure business security and user trust in high data consistency risk scenarios; and decisively save computing power and bandwidth in low-risk scenarios to improve system throughput and economic benefits.

[0050] Furthermore, the discrepancy in vehicle status between the platforms is determined based on whether the vehicle status of the same rental vehicle is consistent between the platforms.

[0051] It is understood that the vehicle status includes both leased and unleased.

[0052] Specifically, such as Figure 3 As shown, the method for determining the dynamic update method of the platform's listing management platform is as follows: In this embodiment, within a multi-platform vehicle rental ecosystem, a dynamic designation mechanism for the "listing management platform" is established, based on verification and confirmation, and capable of adapting to changes in risk conditions. Its core logic is "evidence-driven, focusing on deterioration, and dynamic accountability." By continuously monitoring and statistically analyzing the total number of inconsistencies in vehicle status confirmed by independent verification mechanisms across platforms, "high-risk associations" between platforms are identified. Then, based on the overall structure of the risk network (global outbreak or localized existence), the "management focus" (i.e., the identity of the listing management platform) is dynamically assigned to the platform with the most prominent inconsistency or the one experiencing significant deterioration. This ensures that management resources are always directed towards the "source of the problem" that most needs correction and monitoring, thereby achieving precise governance and risk prevention.

[0053] In one possible embodiment, within an ecosystem consisting of five platforms (P1, P2, P3, P4, and P5), a vehicle can be rented on any of them. The core issue is that when a vehicle is rented on platform A, platform A fails to promptly update its status to "rented," causing other platforms (such as B and C) to still display "rentable," resulting in a conflict. Using the verification mechanism established in the above steps, the root cause of the inconsistency can be determined as "a platform failing to update its status promptly after renting." This method makes periodic decisions based on the number of inconsistencies confirmed by verification as being caused by this reason.

[0054] S21 determines the number of times the vehicle state is inconsistent between the platform and other platforms based on the deviation of vehicle state between the platforms; "Number of inconsistencies" here specifically refers to the cumulative count of state conflict events that have been confirmed as genuine and valid through an authoritative verification process. It represents the strength of objective evidence of data collaboration failure between platforms, which is the cornerstone of the credibility of the entire dynamic update mechanism. Only "number of verification inconsistencies" is used, i.e., state differences caused by issues such as data synchronization delays.

[0055] Specific examples: The verification mechanism confirmed the following inconsistencies: Between P1 and P2, there were a total of 8 inconsistencies; between P2 and P3, there were 6 inconsistencies; between P1 and P3, there were 3 inconsistencies; and between P4 and P5, there were 4 inconsistencies (none of which exceeded the threshold of 5 inconsistencies). The system recorded the total number of these verified inconsistencies.

[0056] S22 designates other platforms that have more than a preset threshold number of inconsistencies with the platform as risk platforms; "Risk platforms" refers to other platforms with which the current platform has frequent and verifiable data conflicts. This is a directed relationship, indicating that from the current platform's perspective, the other party is the one with the most serious collaboration problems.

[0057] This step extracts key "problem pairs" from massive inter-platform interactions. Setting thresholds (e.g., 5 times) prevents the amplification of occasional, low-frequency inconsistencies. The dynamically generated list of risk platforms clearly outlines the current "primary conflicting party" for each platform, which is a crucial input for determining the direction of control responsibility.

[0058] Specific example (continuous): Based on data from S21, the preset threshold is 5 times.

[0059] For platform P1: the number of inconsistencies with P2 is 8 (>5), therefore P2 is a risk platform of P1. It also has 3 instances where the threshold was not reached with P3.

[0060] For platform P2: its 8 interactions with P1 and 6 interactions with P3 all exceeded the threshold, therefore P1 and P3 are both risk platforms of P2.

[0061] For platform P3: it exceeds the threshold 6 times with P2, therefore P2 is a risk platform of P3.

[0062] The four instances between platforms P4 and P5 did not exceed the threshold, therefore there are currently no risky platforms for P4 and P5.

[0063] S23 determines the dynamic update method of the listing control platform in the platform based on the risk platform data of different platforms.

[0064] It should be noted that if all platforms have risky platforms, then the platform with new inconsistencies in vehicle status or an increase in the number of risky platforms will be updated as the platform for listing and management.

[0065] Scenario 1: A globally high-risk network is dynamically detected (all members are at risk): In this state, the system is considered to have entered a high-risk period. The most sensitive "deterioration triggers" rule is adopted: for any platform, as long as a new verification inconsistency event occurs in its risk platform list, or a new risk platform is added to the list (increasing the number), the platform will be immediately dynamically updated to the list management platform for this period.

[0066] When data conflicts and associations are widespread across the entire network, it means that the collaborative mechanism may fail on a large scale. At this time, any local escalation of conflict (new event) or diffusion of relationships (new risk platform) may be a precursor to systemic collapse. Intensive monitoring and intervention are required to curb the networked spread of risk as quickly as possible. Since P5 does not have a risk platform in this embodiment, proceed to the next step.

[0067] Additionally, it's understandable that if not all platforms contain risky platforms, the following content would also be included: S231 Obtain the number of risky platforms in different platforms, determine the risk coefficient of the platform based on the proportion of the number of risky platforms in all platforms, and determine whether there are platforms with a risk coefficient greater than a preset risk coefficient threshold. If yes, proceed to step S232. If no, update the platforms whose increase in the number of risky platforms is greater than a preset increase threshold or whose number of inconsistencies added in the risky platforms is greater than a preset number of times as the listing control platform. Identify the "central node" of the risk network: Calculate the risk coefficient of each platform in the current period, i.e. (number of risky platforms for this platform) / (total number of platforms - 1). Then determine whether there are any platforms with a risk coefficient greater than the preset risk coefficient threshold (0.4).

[0068] The "risk coefficient" dynamically measures how central a platform is in the current risk network. A high coefficient (e.g., >0.4) means that the platform has high-frequency data conflicts with a significant proportion of other platforms. If no such conflicts exist, it indicates that the synchronization anomalies between different platforms are not very serious. Therefore, a lenient approach can be used to determine the platforms to be placed under control (platforms whose number of new risk platforms exceeds a preset threshold or whose number of new inconsistencies exceeds a preset value (e.g., 2 times) are updated as platforms to be placed under control).

[0069] Specific example (continuous local risk scenario): Total number of platforms = 5. The number of risky platforms for platform P2 is 2 (P1, P3), and its risk coefficient = 2 / (5-1) = 0.5. The risk coefficients for platforms P1 and P3 are both 0.25, while those for P4 and P5 are 0. The preset risk coefficient threshold is 0.4, therefore platform P2 (0.5 > 0.4) is identified and proceeds to S232.

[0070] S232 platforms with risk coefficients greater than a preset risk coefficient threshold are selected as risk platforms. It is determined whether the number of selected risk platforms is greater than a preset number of selection platforms. If so, platforms with new vehicle status inconsistencies or an increase in the number of risk platforms are updated as the management and control platforms. If not, proceed to step S233. All platforms with risk coefficients exceeding the threshold are marked as risk-sensitive platforms, and their number is checked to see if it exceeds the preset screening limit (1). This step aims to distinguish between a "single core problem" and a "multi-center parallel problem." If there is only one risk-sensitive platform (such as P2), the problem is relatively concentrated, and differentiated restriction strategies can be determined. If the number of risk-sensitive platforms is greater than one, it indicates that the synchronization anomaly among different platforms is quite severe. To avoid poor user experience caused by synchronization anomalies, a more lenient approach is needed to identify and handle update control platforms.

[0071] Specific example: In this cycle, only P2 is screened for risk, with a quantity of 1, which is not greater than the preset value of 1 (the condition "greater than" is not met). Therefore, the global sensitive policy is not triggered, and the process proceeds to S233.

[0072] S233 determines whether there is a risky platform. If so, the platform with new inconsistencies in vehicle status or an increase in the number of risky platforms is updated as the listing management platform. If not, the platform with an increase in the number of risky platforms that exceeds a preset increase threshold is updated as the listing management platform.

[0073] For nodes on risky platforms (at-risk nodes): a sensitive trigger is used. As soon as any party in its risk platform list causes a new verification discrepancy with it, or if a new member is added to its list, the node is immediately updated to the current period's platform management and control platform.

[0074] For nodes that do not have any risk platforms in this period (clean nodes): a mild triggering method will be used. They will only be updated to be managed platforms when the number of risk platforms they have increased from zero to one or significantly (for example, the increase exceeds a preset increase threshold, such as 1).

[0075] This represents the optimal dynamic allocation of control resources. For platforms already at risk, any deterioration in their associated relationships is a critical signal requiring immediate intervention and control. For currently clean nodes, a certain trust buffer is granted, and their monitoring level is only increased when a clear trend of risk deterioration begins to emerge (a significant increase in the number of risky platforms).

[0076] Specific examples (final rulings): For platform P2 (risky platforms {P1, P3}, which are risky nodes): If the verification mechanism confirms that a new inconsistency has occurred between P2 and P1, then according to the sensitive triggering rules, the system will update P2 to the platform under management for this period.

[0077] For platform P4 (currently the risk platform list is empty, and it is a clean node): In the next monitoring cycle, if the cumulative number of inconsistencies between P4 and P5 exceeds the threshold (1), its risk platform list changes from {} to {P5} (the number increases from 0 to 1), and the increase is equal to the preset increase threshold 1. According to the mild triggering rule, P4 cannot be updated to the platform under management.

[0078] Specifically, the method for determining the listing control method of the listing control platform is as follows: After dynamically designating one or more "listing and management platforms," ​​a specific scope and strategy for control are "tailor-made" for each platform. This aims to minimize the impact of platform control on the number of rental vehicles listed on different platforms while ensuring effective control of core risks, thus guaranteeing rental revenue. The core logic is "macro-level setting, meso-level classification, and micro-level adjudication." First, starting from the overall system, the basic intensity and scope of control are determined based on the total number of currently deployed control platforms. Second, within this framework, each control platform is further classified based on its historical conflict characteristics to determine whether "precise control" or "comprehensive control" is appropriate. Finally, for cases that are difficult to classify, a refined adjudication is made by calculating a quantified "risk coefficient." This achieves the determination of the control scope and objectives for rental vehicles on different platforms from the perspective of synchronized risk, resulting in a balanced control of risk and revenue.

[0079] S31 determines the number of management platforms to be listed based on the data from the listing management platform; "The number of platforms under management" refers to the number of platforms that the system determines in the early stages, where rental vehicles need to be managed due to the risk of synchronization of rental status with other platforms.

[0080] Understandably, if the number of management platforms is already large (greater than the threshold, for example, >3), it means that the system has already achieved effective control of the synchronous risks between different platforms by using the management platforms. Therefore, in order to minimize the impact of management on the exposure of rental vehicles, a lenient approach is adopted to manage rental vehicles listed on the management platforms.

[0081] The above step S31 also includes the following cases: Scenario 1: If the number of the listed management platforms is greater than the preset threshold for the number of management platforms, then the management intensity is relatively high. Therefore, the listing management method of the listed management platform is determined to be that management processing is only required on the risk platform of the listed management platform, that is, the vehicles on the listed management platform and the risk platform are inconsistent.

[0082] Case 2: If the number of the listed management platforms is not greater than the preset threshold for the number of management platforms, then it is determined whether the number of the listed management platforms is less than the preset value for the number of management platforms. If so, the listing management method for the listed management platforms is to manage all management platforms that have inconsistencies with the listed management platforms in the past, that is, the vehicles between the listed management platforms and the management platforms that have inconsistencies with the listed management platforms in the past are inconsistent. If not, proceed to step S32.

[0083] Scenario 1: Number of management platforms > 2 (preset threshold): Strategy (Precise Control Tone): Due to sufficient control resources, all control platforms adopt the "precise control" method, which means that their control is limited to dealing with the inconsistency between the vehicle status and their own risk platform. In other words, when listing, the rental vehicles listed on the control platform are not consistent with the rental vehicles listed on the risk platform.

[0084] Specific example (hypothetical scenario): If there are currently 4 control platforms (P1, P2, P3, P4), where 4 > 2, then regardless of the historical conflicts of P1, P2, P3, and P4, they only need to focus on their own risk platform. For example, P2 only needs to ensure that the vehicles it lists are inconsistent with its risk platforms (such as P1 and P3).

[0085] Scenario 2: Number of management platforms ≤ 1 Further determination is needed to determine whether the quantity is ≤1 (the preset value for the number of control platforms).

[0086] If the number is ≤1: The number of control platforms is extremely small (only 1), and the responsibility of this platform is extremely heavy. Using the "comprehensive control" method, this control platform must ensure that vehicles are consistent with all platforms that have historically had inconsistencies with it when they are listed.

[0087] If the number is greater than 1 and less than 3: the number of control platforms is moderate and a simple decision cannot be made. It is necessary to proceed to step S32 to conduct an individualized in-depth analysis of each control platform.

[0088] Specific example (continuous): Currently, the managed platforms are P2 and P4, with a quantity of 2. This value is less than 3 (case 2) and greater than 1. Therefore, "comprehensive control" is not triggered directly, and the process proceeds to step S32 for refined analysis.

[0089] S32 determines the number of times the vehicle status is inconsistent between the online management platform and other platforms based on historical deviation data of vehicle status between the online management platform and other platforms. The above steps include the following: S321 determines the risk platform of the platform based on the number of times the vehicle status is inconsistent between the platform and other platforms, and judges whether the number of risk platforms of the platform is greater than the preset value of the number of risk platforms. If so, only the risk platforms of the platform need to be managed, that is, the vehicles are inconsistent between the platform and the risk platforms. If not, proceed to step S322. S322 determines whether the proportion of the listed management platform in the listed management platform is greater than the preset value of the number of risk platforms. If so, the listing management method in the remaining listed management platforms is to manage all management platforms that have inconsistencies with the listed management platform in the past. That is, the vehicles of the listed management platform are inconsistent with the management platform that has inconsistencies with the listed management platform in the past. If not, proceed to step S33.

[0090] For each currently listed management platform (P2 and P4), a list of individual risk platforms is determined based on the number of times its historical vehicle status is inconsistent with all other platforms, and a preliminary strategy classification is performed.

[0091] Step S321: Determine if the risk is highly concentrated: For each control platform, determine whether the number of its risk platforms is greater than the preset value for the number of risk platforms (2).

[0092] Keyword Explanation: "Risk Platform" refers to a platform whose historical inconsistencies with the control platform exceed a severe threshold, representing the most intense and frequent source of conflict. "Number of Risk Platforms" directly quantifies the number of platforms with inconsistencies that the control platform ensures are maintained during vehicle registration, thus illustrating the degree of impact of the risk control platform on improving overall synchronization risk.

[0093] If a management platform has serious conflicts with multiple (more than two) platforms simultaneously, it means that ensuring the rental vehicles listed on these risky platforms are inconsistent can effectively reduce synchronization risks and minimize the impact on the platforms listing the rental vehicles. Therefore, prioritizing the handling of the most urgent risky platforms with all resources is a pragmatic strategy of "solving the main contradictions first."

[0094] Specific example (continuous): Obtaining historical inconsistencies between P2 and P4 (verification data from the past month): Control platform P2: inconsistent with P1 10 times, inconsistent with P3 8 times, and inconsistent with P5 2 times (preset risk assessment threshold, such as 5 times). Therefore, the risk platforms for P2 are {P1, P3}, with a quantity of 2.

[0095] Control platform P4: inconsistent with P2 once, inconsistent with P3 six times, and inconsistent with P5 seven times. Therefore, the risk platforms for P4 are {P3, P5}, with a quantity of 2.

[0096] Judgment: The number of risk platforms (2) in P2 is not greater than the preset value (2); the number of risk platforms (2) in P4 is not greater than the preset value (2). Therefore, neither P2 nor P4 meets the condition of "highly concentrated risk", proceed to step S322.

[0097] Step S322: Assess the impact of group strategy tendencies: Calculate the proportion of platforms with more than two risk platforms among all current management and control platforms. This proportion reflects the prevalence of "highly concentrated problem" platforms within the management and control platform group.

[0098] This step involves "strategy calibration" from a group behavior perspective. If most of the managed platforms (exceeding a threshold, such as 50%) are highly concentrated in terms of problems and therefore employ "precise control," then the inconsistency of rental vehicles across different platforms within the entire system is not strictly limited. In this environment, for a few platforms with less concentrated risks, a more stringent control approach is often required. This means that all managed platforms with historical inconsistencies with the listed managed platforms will be subject to control measures, i.e., vehicle inconsistencies between the listed managed platforms and those with historical inconsistencies with the listed managed platforms.

[0099] Specific example (continuous): The current control platforms are P2 and P4, both with 2 risk platforms each; there are no platforms with more than 2. Therefore, the proportion of control platforms with more than 2 risk platforms is 0%. The preset control platform proportion threshold is 50%; 0% < 50%, the condition is not met. This indicates that there is no obvious tendency for "focused attack" within the group, therefore no strategy calibration is needed, and the process proceeds to step S33 for the final comprehensive decision.

[0100] S33 determines the listing control method for the listing control platform based on the number of listing control platforms and the number of times the vehicle status of the listing control platform is inconsistent with other platforms.

[0101] Specifically, the above steps include the following: Based on the number of times the vehicle status is inconsistent between the platform and other platforms, the platforms with inconsistent status are identified. Combined with the risk platforms of the platform, the risk coefficient of the platform is determined. Based on the risk coefficient, the platform listing control method is determined.

[0102] It is understood that the risk coefficient of the listing management platform is determined based on the proportion of risky platforms on the listing management platform among platforms with inconsistencies. It is determined whether the risk coefficient of the listing management platform is greater than a preset risk coefficient threshold. If so, then only the risky platforms on the listing management platform need to be managed, that is, the vehicles on the listing management platform and the risky platforms are inconsistent. If not, then the listing management method of the listing management platform is to manage all management platforms that have inconsistencies with the listing management platform in the past, that is, the vehicles on the listing management platform are inconsistent with the management platforms that have inconsistencies with the listing management platform in the past.

[0103] For management platforms that have not yet determined a strategy after the aforementioned steps, a comprehensive quantitative indicator—the risk coefficient—is used for the final decision. This coefficient combines the quantitative background of the management platform with its own historical conflict structure.

[0104] Calculate the risk coefficient: For each control platform, its risk coefficient = (number of risky platforms) / (total number of platforms with historical inconsistencies). "Platforms with historical inconsistencies" refers to platforms that have had any number of inconsistencies with this control platform (even just once).

[0105] The "risk coefficient" is a ratio between 0 and 1, which precisely measures the proportion of historical conflicts on the control platform that are concentrated on a few "high-risk" objects. The higher the coefficient, the more effectively the restrictions on the listing of rental vehicles on the risk platform are avoided, preventing synchronization anomalies between vehicles listed on the control platform and other platforms.

[0106] This is the most refined basis for decision-making, revealing the "quality" of the conflict rather than just its "quantity." If the risk coefficient is high (e.g., > 0.6), "precise control" allows for less stringent control over the rental vehicle listing platform, minimizing the impact on the rental vehicles themselves, while still generating effective revenue. If the risk coefficient is low, indicating that the problems are scattered, "precise control" may miss many risk points, thus necessitating "comprehensive control" to ensure safety. This achieves the ultimate trade-off between "control efficiency" and "control coverage" at the individual level.

[0107] Specific examples (final rulings): For the management platform P2: Risk platforms: {P1, P3}, quantity = 2; platforms with inconsistent history: {P1, P3, P5} (with 2 records with P5), total = 3; risk coefficient = 2 / 3 ≈ 0.67; judgment: 0.67 > preset risk coefficient threshold 0.6; decision: P2 adopts "precise control", and its control responsibility is only to ensure that the rental vehicles with risk platforms P1 and P3 are not consistent when they are listed.

[0108] For the control platform P4: Risk platforms: {P3, P5}, quantity = 2, platforms with inconsistent history: {P2, P3, P5} (with 1 record with P2), total = 3, risk coefficient = 2 / 3 ≈ 0.67, judgment: 0.67 > 0.6.

[0109] Decision: P4 also adopts "precise control", and its control responsibility is only to ensure that the rental vehicles are not consistent with those of the risk platforms P3 and P5 when they are listed.

[0110] In this application, by intelligently switching and allocating between "precise control" (high efficiency, low coverage) and "comprehensive control" (high coverage, low efficiency), the system fundamentally avoids the risks of synchronization and thus minimizes the impact of control on the number of rental vehicles that can be listed on the platform. In this way, while reducing the risk of synchronization, the exposure rate of rental vehicles is guaranteed.

[0111] Specifically, the method for determining the real-time monitoring and scheduling platform in the platform is as follows: Specifically, given the existing listing exclusion policy (S31-S33, prohibiting vehicles from being listed simultaneously on platforms with mutual risks), a dynamic "real-time monitoring and scheduling platform" mechanism is established to assess the effectiveness of the source restrictions and provide data-driven decision-making for the safe relaxation of restrictions and restoration of vehicle listing freedom in the future. Its core logic is "assessing the breadth of restrictions, monitoring changes in conflicts, and seizing opportunities for precise deregulation." By quantitatively analyzing the overall impact of the listing exclusion rule on vehicle cross-platform exposure, it is determined whether high-cost real-time monitoring needs to be initiated. If the impact is widespread or severe, comprehensive real-time monitoring is conducted on the control platform implementing the restrictions to accurately measure the elimination of actual conflicts between it and the risky platforms. Once data confirms that the conflict has been eradicated, the downgrade or removal of the exclusion rule can be triggered. This achieves the goal of "minimizing long-term business constraints on vehicle rentability and platform traffic caused by listing exclusion, while ensuring the fundamental goal of data consistency."

[0112] In a possible specific embodiment, within an ecosystem consisting of five platforms (P1, P2, P3, P4, and P5), the "listing control method" has been determined for the current listing control platform using methods S31-S33. Its essence is a source-level mutual exclusion rule: Management platform P2 (risk platforms are {P1, P3}): Implements "precise control". The rule is: it is prohibited for any vehicle to be listed on both P2 and P1 at the same time, and it is also prohibited for any vehicle to be listed on both P2 and P3 at the same time.

[0113] Management platform P4 (risk platforms are {P3, P5}): Implements "precise control". The rule is: it is prohibited for any vehicle to be listed on both P4 and P3 at the same time, and it is also prohibited for any vehicle to be listed on both P4 and P5 at the same time.

[0114] Full platform listing: Under the current circumstances, all platforms are mutually exclusive, so there is no platform for full listing.

[0115] This mutual exclusion strategy prevents vehicles from simultaneously appearing on known high-risk combinations from the outset. This approach aims to assess the business impact of this strategy and determine which control platforms require focused monitoring so that restrictions can be relaxed in the future when it is safe to do so.

[0116] S41 determines the number of platforms for vehicle listing based on the listing restriction data of different vehicles on different platforms; Since there is no platform that allows all vehicles to be listed, all listing options for a vehicle are subject to mutual exclusion rules. Under this global constraint, the maximum number of "actual listing platforms" that each vehicle can achieve is determined, which is the upper limit of the number of platforms it can be listed on simultaneously, provided that all mutual exclusion rules are followed.

[0117] "Number of platforms for which a vehicle is listed" specifically refers to the maximum number of platforms a vehicle can successfully list on simultaneously, under the strict constraint of complying with all effective mutual exclusion rules (P2-P1, P2-P3, P4-P3, P4-P5 in this example) by optimizing its listing combination. It directly reflects the hard ceiling of cross-platform exposure for a single vehicle under the current rigid rule system.

[0118] Specific example: A system has 100 vehicles that must adhere to four mutual exclusion rules. Analyze the relationships between platforms: Since P3 is mutually exclusive with both P2 and P4, P3 becomes a "conflict center". If a car wants to include P2, it cannot include P1 or P3. If a car wants to include P4, it cannot include P3 or P5. Therefore, the combinations that can be listed at the same time are (P4, P2), (P5, P2), (P3, P5, P1), (P4, P1), etc. In addition, there may be vehicles that are only listed on some platforms.

[0119] Therefore, a vehicle cannot simultaneously contain any two of P2, P3, and P4 (because P3 conflicts with both P2 and P4, while P2 and P4, although not directly conflicting, are indirectly restricted through P3). The algorithm shows that the average maximum number of platforms a vehicle can actually be listed on is 2.25.

[0120] S42 determines the vehicle's listing restriction coefficient based on the proportion of the number of platforms on which the vehicle is listed to all platforms. Based on the actual number of platforms for each vehicle obtained in step S41, calculate its "platform restriction coefficient". The calculation formula is: Platform restriction coefficient for a single vehicle = Actual number of platforms for that vehicle / Total number of platforms (5).

[0121] The "listing restriction coefficient" here represents the actual degree of freedom for a single vehicle to be listed in an environment where there is no full-scale security platform buffer and it is completely subject to a mutually exclusive network. This coefficient is entirely determined by the strength of the mutual exclusion rules; the lower the value, the more stringent the rule system and the worse the business flexibility.

[0122] This step transforms absolute quantities into standardized, aggregateable macro-level metrics. Calculating the average of this coefficient across all vehicles accurately reflects the overall suppression level of the current set of mutual exclusion rules on the overall business flexibility of the vehicle pool. In scenarios without a full platform, this average coefficient is the gold standard for judging whether the system is in a state of "over-control," directly determining whether it is necessary to initiate high-cost monitoring to find possibilities for optimizing (relaxing) the rules.

[0123] Specific example (continuous): Based on the results of step S41, the average number of platforms a vehicle is actually listed on is 2.25. Therefore, the average listing restriction coefficient for the vehicle pool = 2.25 / 5 = 0.45. This means that, due to the mutual exclusion rule, vehicles can only utilize an average of 45% of platform channels, forcibly depriving them of more than half of their potential exposure opportunities.

[0124] S43 uses the vehicle listing data from different platforms to determine the number of vehicles listed on different platforms, and combines this with the vehicle listing restriction coefficient to determine the real-time monitoring and scheduling platform on the platform.

[0125] It should be noted that if a platform is not subject to listing control as required by the listing control method in the above steps, then all vehicles will be listed, and the platform that handles the listing of all vehicles will be considered the full listing platform.

[0126] Furthermore, the proportion of the managed platforms on the platform is taken as the management proportion. If the management proportion is less than the threshold management proportion threshold, then the number of managed platforms is small. Therefore, it is determined that none of the platforms belong to the real-time monitoring and dispatching platform, and the vehicle synchronization status is still identified and processed according to the original synchronous monitoring and identification method.

[0127] Specifically, if the amount of data uploaded to the management platform is small in the above steps, the impact on the exposure of the lease is minimal (e.g., when the management ratio is less than 0.25). Therefore, it is determined that none of the platforms belong to the real-time monitoring and dispatching platform. Additionally, it should be noted that if the controlled proportion is not less than the threshold controlled proportion threshold, the following content is also included: Scenario 1: If the proportion of the listing management platform in the platform is greater than the preset threshold for the proportion of the number of listing management platforms, then all listing management platforms will be used as real-time monitoring and scheduling platforms. This will determine the synchronization status of rental vehicles between the listing management platform and different platforms, and then update the listing management platform. This will ensure that when the abnormality of the synchronization status of the listing management platform is significantly improved, the listing management level of rental vehicles will be reduced.

[0128] If the control ratio is >50% (not triggered in this example), and more than half of the platforms actively formulate rules, it indicates that restrictions are the mainstream behavior in the ecosystem, and the degree of restriction on rental vehicles is relatively high. In this case, all listed control platforms need to be used as real-time monitoring and scheduling platforms. When any rental vehicle on any of the listed control platforms changes, the status should be identified and processed synchronously across all platforms.

[0129] Scenario 2: If the proportion of the listing management platforms in the platform is not greater than the preset threshold for the proportion of listing management platforms, the listing restriction coefficient of the vehicle is used as the basis. If the average of the listing restriction coefficients of different vehicles is less than the preset threshold, all listing management platforms are used as real-time monitoring and scheduling platforms. This determines the synchronization status of rental vehicles between the listing management platform and different platforms, and then updates the listing management platform. This ensures that when the abnormality of the synchronization status of the listing management platform is significantly improved, the listing management level of rental vehicles is reduced.

[0130] Scenario 3: If the average of the listing restriction coefficients of different vehicles is not less than the preset restriction coefficient threshold, the ratio of the number of vehicles listed on the platform to the total number of vehicles is determined based on the number of vehicles listed on different platforms, and this ratio is used as the platform restriction coefficient of the platform. It is then determined whether the platform restriction coefficient of the listing control platform is less than the preset coefficient threshold. If so, the listing control platform is determined as a real-time monitoring and scheduling platform, thereby determining the synchronization status of rental vehicles between the listing control platform and different platforms, and thus processing the update of the listing control platform. This ensures that when the abnormality of the synchronization status of the listing control platform is significantly improved, the listing control level of rental vehicles is reduced. If not, the listing control platform is determined not to be a real-time monitoring and scheduling platform.

[0131] In one possible implementation, if the current control percentage is 40% ≤ 50%, proceed to this branch. Examine the average vehicle deployment restriction coefficient (0.45 in this example).

[0132] Judgment (Entering Situation 2): The average listing restriction coefficient is 0.45, which is less than the preset threshold (0.5). Then all listing control platforms are used as real-time monitoring and scheduling platforms. This determines the synchronization status of rental vehicles between the listing control platform and different platforms, and then updates the listing control platform. This ensures that when the abnormality of the synchronization status of the listing control platform is significantly improved, the listing control level of rental vehicles is reduced.

[0133] Additionally, it should be noted that if the average vehicle listing restriction coefficient is not less than the threshold, the platform restriction coefficient is calculated as follows: For each management platform, its "platform restriction coefficient" is calculated as follows: (the number of vehicles currently actually listed on the platform) / the total number of vehicles in the system, 100). This coefficient reflects its business scale.

[0134] Strategy: Only platforms with a platform limitation coefficient less than a preset threshold (e.g., 0.6) will be designated as real-time monitoring and dispatching platforms. It should be noted that when dividing vehicles, the vehicles will be divided proportionally for combinations that are listed at the same time. If P2 and P4 each have 50 vehicles listed, then P2 and P4 will be designated as real-time dispatching and control platforms.

[0135] Given limited overall flexibility, system resources should be prioritized for monitoring management platforms that can only list a small number of rental vehicles due to their rule restrictions. Real-time monitoring of these platforms is more cost-effective, allowing for rapid verification of whether their rules are overly strict, and thus, based on their reliable synchronization, preventing them from being used as management platforms for vehicle listing as soon as possible.

[0136] It is understandable that if the platform is a real-time monitoring and dispatching platform, then whenever the status of a rental vehicle changes, the consistency of the vehicle status across all platforms will be identified and processed, thereby enabling a comprehensive and reliable determination of the synchronization of vehicle status between the management platform and other platforms.

[0137] Task definition: The designated real-time monitoring and dispatching platform (let's assume it's P4 in this example) has the following task: when the status of any rental vehicle on the platform changes, immediately trigger a vehicle status consistency verification between all platforms (i.e., {P1 to P5}).

[0138] Focus on evaluating specific rules: By monitoring P4 in real time, data can be directly collected to evaluate the actual effect of the two rules, "prohibiting vehicles from being simultaneously listed on P4 and P3" and "prohibiting vehicles from being listed on P4 and P5" (i.e., the consistency of vehicle status between P1 and P5).

[0139] Providing evidence for precise deregulation: If monitoring data shows that there is no inconsistency between P4 and P3 (or P5) for an extended period (e.g., 3 months), it provides strong evidence for lifting the mutual exclusion rule between P4 and the platform. After deregulation, vehicles can be listed on both P4 and the platform simultaneously, directly increasing business flexibility.

[0140] This method embodiment, under the stringent premise of accurately identifying "zero full-scale platforms", constructs a pragmatic decision-making framework of "facing the intensity of restrictions, accurately monitoring deployment, and seeking local breakthroughs". Under the premise of controllable risks, the system can gradually reduce the impact on the listing of rental vehicles on the platform, and reduce the synchronous risks while also potentially reducing the impact on the exposure of vehicles.

[0141] Example 2 Secondly, the present invention provides a computer system comprising: a memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the above-described multi-platform collaborative vehicle status real-time monitoring and scheduling method when running the computer program.

[0142] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0143] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0144] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for real-time monitoring and scheduling of vehicle status based on multi-platform collaboration, characterized in that, Specifically, it includes: Based on the rental vehicle data of each platform, the correlation between rental vehicles on different platforms is determined. Based on the correlation, a synchronous monitoring and identification method for the vehicle status of rental vehicles on different platforms is determined. The synchronous monitoring and identification method is used to determine the deviation of vehicle status between platforms. Based on the deviation, a dynamic update method for the listing management platform in the platform is determined. The dynamic update method is used to update the vehicle listing control platform. Based on the data of the vehicle listing control platform and the historical deviation data of vehicle status between the vehicle listing control platform and other platforms, the listing control method of the vehicle listing control platform is determined. The vehicle listing control method is used to manage the listing of vehicles on the listing control platform. Based on the listing restriction data of different vehicles on different platforms, the real-time monitoring and scheduling platform in the platform is determined.

2. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 1, characterized in that, The rental vehicle data includes rental vehicles from different platforms.

3. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 1, characterized in that, The association of the rental vehicles is determined based on the data of the same rental vehicle being listed repeatedly on different platforms.

4. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 1, characterized in that, The method for determining the synchronous monitoring and identification method for the vehicle status of the rental vehicle is as follows: Based on the association between rental vehicles on different platforms, determine the platform on which the rental vehicle is listed, and use the platform on which the rental vehicle is listed as the listing platform for the rental vehicle; Based on the data from the listing platforms, determine the number of rental vehicles listed on the platforms; A synchronous monitoring and identification method for determining the vehicle status of rental vehicles based on the number of rental vehicles listed on different platforms.

5. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 1, characterized in that, The discrepancy in vehicle status between the platforms is determined based on whether the vehicle status of the same rental vehicle is consistent between the platforms.

6. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 1, characterized in that, The method for determining the dynamic update method of the platform for managing the listing in the aforementioned platform is as follows: The number of times the vehicle status is inconsistent between the platform and other platforms is determined based on the deviation of vehicle status between the platforms. Other platforms that have more than a preset threshold number of inconsistencies with the platform are considered risk platforms. Based on risk platform data from different platforms, determine the dynamic update method for the listing control platform within the aforementioned platform.

7. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 6, characterized in that, If all platforms have risky platforms, then the platform with new inconsistencies in vehicle status or an increase in the number of risky platforms will be updated as the platform for listing and management.

8. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 1, characterized in that, The method for determining the real-time monitoring and scheduling platform in the aforementioned platform is as follows: Based on the listing restrictions of different vehicles on different platforms, determine the number of platforms on which the vehicle will be listed. The vehicle's listing restriction coefficient is determined based on the proportion of the number of platforms on which the vehicle is listed to all platforms. Based on the vehicle listing data on different platforms, the number of vehicles listed on different platforms is determined, and combined with the vehicle listing restriction coefficient, the real-time monitoring and scheduling platform on the platform is determined.

9. The multi-platform collaborative vehicle status real-time monitoring and scheduling method as described in claim 8, characterized in that, The proportion of the managed platforms on the platform is taken as the management proportion. If the management proportion is less than the management proportion threshold, it is determined that none of the platforms belong to the real-time monitoring and scheduling platform.

10. A computer system, comprising: A memory and processor connected by communication, and a computer program stored in the memory and capable of running on the processor, characterized in that, when the processor runs the computer program, it executes a multi-platform collaborative vehicle status real-time monitoring and scheduling method according to any one of claims 1-9.

Images