Bus intelligent scheduling optimization method and system based on multi-source data fusion model

Abstract

The application discloses a kind of based on multi-source data fusion model's public transport intelligent scheduling optimization method and system, it is related to intelligent traffic and public transport operation management technical field, it is applicable to intelligent public transport use scene, including: terminal acquisition continuous sampling operation data and active safety alarm, form local data stream;According to the division of public transport event semantics, generate versioned evidence, report fragment abstract.The terminal receives and analyzes the scheduling instruction generated by the cloud platform based on the abstract, the instruction carries the consistency of evidence, observation freeze control, candidate action and intensity range and effective window, two-stage instruction, instruction sequence number and evidence version binding field;Prepared state is low disturbance and can be revoked, submission state is strong action and executes after meeting the condition.The terminal is processed according to sequence number and version number idempotent and executes in stages.The present application effectively reduces repeated issue, revocation back jump and gate flip, improves execution consistency and replayability.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation and public transportation operation management technology, and in particular to a method and system for intelligent bus scheduling optimization based on a multi-source data fusion model. Background Technology

[0002] With the widespread adoption of onboard terminals, positioning and communication systems, and active safety systems in buses, some dispatching systems have begun to collect continuous sampling operational data such as vehicle speed, location, door status, and interval running time under end-to-end cloud collaboration. This data is then overlaid with active safety alarm events such as distraction and collision warnings, and reported to the cloud platform to generate dispatching suggestions or instructions. The terminal side typically reports location and speed at fixed intervals, such as every 3-10 seconds, and reports an additional time when the vehicle's status changes, such as door opening / closing or entering / leaving a station. Active safety alarms are usually reported immediately upon occurrence, uploading the alarm type, time of occurrence, and level. The cloud platform side often makes judgments based on route timetables and empirical thresholds: for example, if a vehicle is late, it issues instructions such as suggesting speed control / prompting the driver to speed up or suggesting skipping stops / adjusting stop durations. To avoid network packet loss, some systems only include a sequence number in the instruction and require terminal confirmation, or allow the driver to manually confirm / cancel the instruction before execution.

[0003] For example, Chinese invention patent CN119068658B discloses a smart bus dispatching system. This system collects environmental and vehicle characteristic information in real time through an information collection module, and obtains standard passenger transport data such as standard road conditions, standard vehicle conditions, standard passenger flow, and standard time based on planned route information through a dispatch management module. When a vehicle arrives at each route node, the dispatch evaluation module calculates the dispatch value based on the arrival time between adjacent route nodes and the aforementioned standard passenger transport data, thereby realizing dispatch evaluation and early warning dispatch control of the vehicle operation process.

[0004] However, the above approach still has significant shortcomings in the context of cloud-based collaborative scenarios on public transportation platforms, mainly in the following aspects:

[0005] In edge-cloud collaborative bus operation scenarios, dispatching decisions rely on both continuously sampled operational data and event-triggered proactive safety alarm data, both reported to the cloud platform via cellular networks. However, under conditions of weak coverage, congestion, and latency fluctuations, different data sources are prone to misalignment in arrival order, completeness, and temporal semantics: alarm events and continuously sampled data are often coarsely aligned with timestamps; when network jitter or rapid semantic window switching occurs, such as entering / exiting stations, lane changes, or close following, alarms can easily be aligned to different sampling indices or different segments, leading to instability in the cloud's determination of which segment and scenario an alarm belongs to. Meanwhile, the boundary determination of vehicle operation status segments, such as entering, stopping, exiting, and cruising, often relies on speed trends, door status, and proximity information. When terminals report in periods / events, retransmissions, out-of-order arrivals, or anomaly corrections can cause the start and end boundaries of the same operation process to be rewritten in the cloud afterward. Existing systems often lack versioned management for fragment boundary reassessment. In the absence of unified temporal semantics and evidence consistency constraints, cloud platforms are prone to conduct risk assessments based on different versions of fragment boundaries, statistical calibers, or alarm attribution results within adjacent decision-making cycles. This leads to frequent changes in candidate action ranking, gating conclusions, or deviation judgments, creating potential risks for subsequent scheduling errors.

[0006] Current bus dispatching systems generally adopt a single-stage dispatching instruction issuance method, meaning that dispatching instructions take effect immediately upon issuance, and are mostly based on a single deviation threshold or bare alarm trigger. This method does not set engineering constraints on evidence stability, instruction execution process, and execution result feedback, and the problems are particularly prominent when high-disturbance, strong actions such as skipping stops, short-line reversals, and point-tracking prompts are involved in dispatching. Strong actions such as skipping stops and strong speed control can temporarily change the statistical patterns of vehicle arrival times, interval running times, and bus intervals; existing systems often lack anti-disturbance risk constraints and gray-zone buffer mechanisms before actions, causing strong actions to trigger new deviations, and cloud-based corrections to trigger new actions, resulting in policy back-and-forth swings. Even with the introduction of mechanisms such as sequence numbers, receipts, retransmissions, or prompts before execution, these usually only solve the message delivery problem and cannot guarantee that the instruction is consistent with the current evidence; when evidence is re-evaluated or drifted in the cloud, instructions generated from old evidence may still be executed or revoked, manifesting as duplicate issuance, conflicting instructions, gated conclusion reversals, and receipt mismatches, among other backend errors.

[0007] Existing solutions often lack a mechanism to bind fragment identifiers, evidence versions, instruction sequences, and execution evidence into evidence packages. This makes it difficult to pinpoint afterward whether evidence drift occurred during cloud-based aggregation, alignment, and fragment boundary / alarm attribution / statistical caliber updates of terminal-reported data; whether it occurred during cloud-based risk scoring and gating of candidate actions based on updated evidence; or whether it occurred during the interaction between terminal action execution and cloud-based revocation / degradation control, especially amplified under conditions of delayed, retransmitted, or out-of-order transmission. These problems lead to unstable results and difficulty in automatically adjusting thresholds and window parameters, ultimately resulting in low scheduling efficiency for the entire intelligent bus dispatching system and hindering true intelligence. Therefore, there is an urgent need for a method and system for optimizing intelligent bus dispatching that can version-manage dispatching evidence, provide rollback and irreversible constraints on dispatching instruction execution, and achieve quantifiable evaluation and feedback adjustment through evidence logging, under conditions of unstable multi-source data, easily triggered false alarms, and fluctuating network latency. This would reduce the risk of back-end dispatching errors and improve the consistency and reproducibility of dispatching decisions. Summary of the Invention

[0008] This invention provides a method and system for optimizing intelligent bus scheduling based on a multi-source data fusion model. It can stabilize multi-source operational data and proactive safety alarm evidence under end-cloud collaboration, and enable risk-controlled issuance and rollback control of candidate scheduling actions. This reduces the risk of repeated and erroneous backend scheduling strategies and improves the stability, consistency, and reproducibility of scheduling decisions in scenarios where cellular network latency fluctuations, false alarm triggering, and strong action disturbances coexist.

[0009] The technical solutions provided in this application are as follows:

[0010] A public transport intelligent scheduling optimization method based on a multi-source data fusion model, for use in terminals:

[0011] S1: Collects continuous sampling data and proactive security alarm event data to generate local data streams on the terminal.

[0012] S2: Segment the operational status into segments based on the semantics of bus operation events and generate versioned evidence, then report the segment summaries to the cloud platform. The segment summary should include at least the segment identifier, segment boundary information, evidence version number, and segment operation summary.

[0013] S3: Receive and parse the scheduling instructions issued by the cloud platform. The scheduling instructions are generated by the cloud platform based on information reported by the terminal and include: an evidence version consistency determination identifier, an observation / freeze control identifier, a candidate scheduling action set identifier or action parameter set, intensity level and effective window parameters, a two-stage instruction, an instruction sequence number, and a field bound to the evidence version number. The two-stage instruction includes a preparatory state instruction and a submission state instruction. The preparatory state instruction corresponds to low-disturbance actions and carries a cancellation window parameter, while the submission state instruction corresponds to strong actions and carries submission condition parameters.

[0014] S4: After receiving the scheduling instruction, perform data processing based on the instruction sequence number and evidence version number, and execute according to the two-stage mechanism of preparatory state and submission state. In the preparatory state, the execution state summary is continuously transmitted back within the cancellation window. In the submission state, after the strong action reaches the irreversible threshold, cancellation is prohibited and only compensation actions are allowed.

[0015] The operational status segments are divided according to the semantics of bus operation events, and segment identifiers and segment boundaries are generated. The semantics of bus operation events include at least station-related semantics and non-station semantics. Station-related semantics include at least one or more of the following: station entry semantics, station stop semantics, and station exit semantics. Non-station semantics include at least one or more of the following: cruise semantics, section operation semantics, close following semantics, or lane change / merge semantics.

[0016] Versioned evidence includes at least an evidence version number and a versioned evidence payload. The evidence version number is generated from at least a fragment identifier, a fragment boundary summary, a summary caliber identifier, and a generation time sequence identifier. The versioned evidence payload includes at least a fragment execution summary and an event mapping summary corresponding to the fragment execution summary. A new evidence version number is generated and bound to a new versioned evidence payload for reporting when any of the following conditions are met: the fragment boundary is re-evaluated due to delayed data or anomaly correction; a change in event mapping rules leads to an update of the alarm attribution index; a change in summary caliber leads to an update of the statistical dimension, sampling period, or binning rules; or a change in evidence integrity status leads to a change in the summary from a missing marker to a valid marker. The type of versioned evidence includes at least one or more of the following: boundary version, attribution version, caliber version, or integrity version. The boundary version is used to characterize the re-evaluation status of the same fragment start and end positions; the attribution version is used to characterize the attribution change after the alarm event is aligned to the sampling index; the caliber version is used to characterize the change in the statistical summary calculation caliber; and the integrity version is used to characterize the change in evidence coverage caused by late re-transmission.

[0017] The received scheduling instructions also include, in the case of evidence version consistency determination, the purification and stability assessment results obtained by the cloud platform from performing evidence purification and stability assessment on consistent evidence. Evidence purification includes at least performing availability discrimination and aggregation measurement on proactive safety alarm evidence to generate alarm availability and alarm cluster density, and performing persistence determination or multi-vehicle consistency determination on operational deviation evidence to generate abnormal confidence. Stability assessment includes at least determining the fluctuation range of segment boundary drift, alarm attribution drift, or summary statistics, and using the stability assessment results to adjust the intensity level or effective window of candidate scheduling actions, or to trigger a downgrade to a low-disturbance action.

[0018] The received scheduling instructions carry the risk scores and gating conclusions corresponding to the candidate scheduling actions. The gating conclusions include allow, reject, and gray zone. The gray zone represents the gating state corresponding to a risk score falling within the intermediate risk range between the allow and reject thresholds. When the gating conclusion is in the gray zone, only the preparatory action is executed, and the reporting cycle / duration of the evidence window is extended to trigger the data updates required for subsequent rolling re-determination.

[0019] The risk score generation basis field and / or risk assessment feature summary field are constructed by the cloud platform based on the risk assessment feature vector corresponding one-to-one with the candidate scheduling action during the pre-action risk assessment of the candidate scheduling action. The risk assessment feature vector includes at least one or more of the following: longitudinal response statistical features and alarm event statistical features obtained from the segment operation summary, evidence stability features obtained from evidence version consistency determination, and action intensity profile features obtained from the candidate scheduling action, its intensity level, and effective window. Among them, the evidence stability features include at least one or more of segment boundary re-estimation markers, alarm attribution drift, evidence version drift, or arrival disorder intensity. The action intensity profile features include at least one or more of strong action disturbance sensitivity, anti-disturbance prediction deviation index, or disturbance cost indicator. The anti-disturbance prediction deviation index is used to characterize the degree of reverse disturbance of the candidate strong action on the arrival prediction deviation, interval running time deviation, or shift interval deviation.

[0020] The gating conclusion is obtained by the cloud platform based on the risk score and combined with the release threshold and rejection threshold to form a gray zone. When the risk score falls into the gray zone and the gating conclusion is gray, only the corresponding candidate scheduling action is allowed to enter the preparatory state, and the evidence window is extended according to the rolling re-determination trigger parameter in the instruction for data feedback of rolling re-determination. Rolling re-determination includes at least: continuously feeding back the execution state summary and the updated fragment execution summary within the extended evidence window, so that the cloud platform can update the risk score based on the updated evidence version consistency determination result, and send the updated risk score and gating conclusion to the terminal through subsequent scheduling instructions. When the updated risk score carried by the subsequent scheduling instruction received by the terminal meets the release condition and the evidence version consistency meets the stability condition in at least K consecutive rolling re-determinations, it is allowed to enter the submission state and execute the submission state strong action. When the updated risk score carried by the subsequent scheduling instruction received by the terminal meets the rejection condition or the evidence version consistency becomes unstable, the candidate scheduling action is rejected or downgraded to a low-disturbance action for execution. When the scheduling instruction received by the terminal carries a freeze window trigger flag indicating that the number of times the gating conclusion has been flipped within an adjacent decision cycle has reached a preset limit or the gray zone dwell time has exceeded a preset limit, the terminal enters the freeze window. Within the freeze window, strong actions in the submission state are prohibited, and only low-disturbance actions in the preparatory state are allowed. The received scheduling instruction also carries a gating reason summary, which is generated by the cloud platform when rejecting, downgrading, or triggering the freeze window and is associated with the corresponding evidence version number.

[0021] Step S4 further includes: transmitting the execution evidence summary, which involves associating the fragment summary, execution state summary, and execution evidence summary with the corresponding fragment identifier, evidence version number, and instruction sequence number. This supports the cloud platform in aggregating evidence packages by fragment identifier and calculating the background error indicator set accordingly. The system receives the control parameter adjustment results issued by the cloud platform after triggering degradation conditions based on the background error indicator set, and updates the terminal execution strategy based on the control parameter adjustment results, thereby forming an evaluation feedback adjustment closed loop to suppress background errors.

[0022] A public transport intelligent dispatch optimization system based on a multi-source data fusion model is provided for a terminal. The system includes: a data acquisition module, a segmentation and evidence generation module, a summary reporting module, an instruction receiving, parsing, and registration module, and a two-stage execution and feedback module. The data acquisition module collects continuously sampled data and proactive safety alarm event data, generating a local data stream for the terminal. The segmentation and evidence generation module segments operational status segments according to the semantics of public transport operation events and generates versioned evidence. The summary reporting module reports segment summaries to the cloud platform. The instruction receiving, parsing, and registration module receives dispatch instructions issued by the cloud platform and parses and registers them. The dispatch instructions are generated by the cloud platform based on information reported by the terminal and include: an evidence version consistency determination identifier, an observation / freeze control identifier, a candidate dispatch action set identifier or action parameter set, intensity level and effective window parameters, a two-stage instruction, an instruction sequence number, and a field bound to the evidence version number. The two-stage instruction includes a preparatory state instruction and a submission state instruction. The preparatory state instruction corresponds to a low-disturbance action and carries a cancellation window parameter, while the submission state instruction corresponds to a strong action and carries submission condition parameters. The two-stage execution and feedback module is used to receive scheduling instructions and perform data processing based on the instruction sequence number and evidence version number. It is executed according to a two-stage mechanism of preparation state and submission state. In the preparation state, the execution state summary is continuously fed back within the cancellation window. In the submission state, after the strong action reaches the irreversible threshold, cancellation is prohibited and only compensation actions are allowed.

[0023] A public transport intelligent scheduling optimization method based on a multi-source data fusion model, used on a cloud platform, includes the following steps:

[0024] A1: Receive the segment summary reported by the terminal. The segment summary is obtained by the terminal based on the semantic segmentation of the bus operation event and the generation of versioned evidence. The segment summary includes at least the segment identifier, segment boundary information, evidence version number, and segment operation summary.

[0025] A2: Perform scheduling generation processing based on fragment summaries to form candidate scheduling actions. This processing includes at least: performing evidence version consistency determination and generating an evidence version consistency determination identifier. When inconsistency is determined, generate an observation / freeze control identifier to trigger observation or freezing. When consistency is determined, generate candidate scheduling action set identifiers or action parameter sets, and configure intensity level parameters and effective window parameters for the candidate scheduling actions.

[0026] A3: Generate and issue scheduling instructions. These instructions must include at least an evidence version consistency determination identifier, an observation / freeze control identifier, a candidate scheduling action set identifier or action parameter set, intensity level and effective window parameters, a two-stage instruction, an instruction sequence number, and a field bound to the evidence version number. The two-stage instruction indicates the preparatory state and the commit state. The preparatory state instruction corresponds to low-disturbance actions and carries a cancellation window parameter, while the commit state instruction corresponds to strong actions and carries commit condition parameters.

[0027] A4: Submission determination and status update are based on a two-phase mechanism. After issuing the preparatory state command, the system receives the execution state summary and the updated fragment execution summary corresponding to the current fragment identifier from the terminal within the cancellation window. Submission conditions are then determined based on the updated evidence version number and the evidence version consistency determination flag. When the submission conditions are met, a submission state command bound to the same evidence version number is issued. When the submission conditions are not met or the observation / freeze control flag is triggered, issuing the submission state command is prohibited, and the preparatory state low-disturbance action is maintained, or cancellation / degradation control information is generated.

[0028] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0029] 1. By segmenting operational status into segments based on the semantics of bus operation events and generating segment identifiers and boundaries, and by including evidence version numbers in the segment summaries and generating new boundary versions when reassessment is triggered by delayed data / anomaly corrections, the cloud can distinguish different boundary definitions for the same operational process. Compared to existing technologies that only report periodically or rely solely on timestamp slices, making it difficult to identify post-event reassessment situations, this technology achieves traceable, versioned management of segment boundaries, thereby reducing redundant decisions and policy iterations caused by boundary reassessment.

[0030] 2. By including both the fragment execution summary and its corresponding event mapping summary in the versioned evidence payload, and generating a new attribution version when the attribution index is updated due to changes in event mapping rules, alarm attribution changes are explicitly solidified into a determinable version difference. Compared to existing technologies that only perform coarse alignment, leading to alarm drift between different fragments and difficulty in stable gating, this achieves interpretable and replayable version binding of alarm attribution, thereby reducing gating flips and false triggering caused by attribution drift.

[0031] 3. By using a cloud platform, under the premise that the evidence version consistency is determined to be consistent, evidence purification and stability assessment are performed on consistent evidence. Based on the assessment results, the intensity level and effective window of candidate scheduling actions are adjusted or downgraded to low-disturbance actions. This suppresses false alarm triggering and statistical fluctuation amplification in advance during the action generation stage. Compared with existing technologies that directly issue strong actions based on original alarms and short-term fluctuations, resulting in amplified anti-disturbance deviations, this achieves pre-constraints for controllable issuance of strong actions, thereby reducing the risk of secondary amplification of arrival / interval / interval prediction deviations caused by strong actions.

[0032] 4. By performing evidence version consistency checks in the cloud and triggering observation or freezing for inconsistent evidence, a two-stage scheduling instruction bound to the evidence version number is generated and an instruction sequence number is set. This ensures that the validity of the instruction is controlled by both the evidence version and the sequence. Compared to existing technologies that rely solely on sequence number deduplication or staged prompts without binding evidence criteria, this approach achieves natural invalidation and suppression of old instructions when evidence changes, thereby reducing the probability of duplicate and conflicting instructions.

[0033] 5. Data processing is performed via the terminal according to the instruction sequence number and evidence version number, executing a two-stage mechanism of preparatory and submission states. During the preparatory state, an execution state summary is continuously transmitted back within the revocation window. During the submission state, once a strong action reaches the irreversibility threshold, revocation is prohibited, and only compensatory actions are allowed. This engineered and solidified boundary between revocable and irreversible actions. Compared to existing technologies where revocation / confirmation often relies on manual intervention or lacks irreversibility threshold constraints, making them prone to bounces, this technology achieves stable control over the strong action execution process, thereby reducing revocation bounces and execution jitter.

[0034] 6. The terminal associates and transmits fragment summaries, execution state summaries, execution evidence summaries, fragment identifiers, evidence version numbers, and instruction sequence numbers. The cloud aggregates these fragments into evidence packages based on their identifiers and calculates a set of background error indicators. When degradation conditions are met, it automatically adjusts control parameters such as thresholds, window durations, hysteresis intervals, cooldown periods, and strong action levels, and records parameter changes. This forms an assessment-feedback-adjustment closed loop to suppress background errors. Compared to existing technologies that lack evidence packages and quantitative indicators, leading to reliance on manual investigation, this approach achieves quantifiable, replayable, and self-calibrating closed-loop governance, thereby improving long-term stability under complex network jitter and semantic switching in complex scenarios.

[0035] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0036] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein:

[0037] Figure 1 This is a flowchart illustrating a method for intelligent bus scheduling optimization based on a multi-source data fusion model, provided by an embodiment of the present invention, and its application to a terminal.

[0038] Figure 2 This is a schematic diagram of the structure of a public transport intelligent scheduling and optimization system based on a multi-source data fusion model provided in an embodiment of the present invention;

[0039] Figure 3 This is a flowchart illustrating a method for intelligent bus scheduling optimization based on a multi-source data fusion model, provided by an embodiment of the present invention, and its application to a cloud platform.

[0040] Figure 4 This is a schematic diagram of the cloud-edge collaborative bus scheduling optimization method according to an embodiment of the present invention. Detailed Implementation

[0041] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0042] In this embodiment of the invention, a public transport intelligent scheduling optimization method based on a multi-source data fusion model is deployed in an end-to-cloud collaborative architecture of "safe driving assistance terminal + cloud platform". For example... Figure 4 As shown, Figure 4 This is a schematic diagram of the end-to-cloud collaborative bus dispatch optimization method provided in an embodiment of the present invention. The method utilizes safe driving assistance and a cloud platform in collaboration to suppress backend system errors caused by the cloud platform under conditions of limited links and inconsistent evidence. These backend system errors include one or more of the following: duplicate issuance, revocation followed by a bounce and re-issuance, coexistence of conflicting instructions, and frequent reversals of risk gating conclusions within adjacent decision-making cycles.

[0043] The safe driving assistance terminal is installed in the vehicle's cockpit and connects to active safety cameras, vehicle control bus interfaces (such as CAN, controller area network) / vehicle diagnostic interfaces (such as OBD, vehicle diagnostic interface, positioning module, and status acquisition interfaces for doors / turn signals, etc.). Meanwhile, the cloud platform is deployed on the dispatch center server cluster.

[0044] Embodiment 1 of the present invention provides a method for intelligent bus scheduling optimization based on a multi-source data fusion model, such as... Figure 1 The flowchart shown illustrates a public transport intelligent scheduling optimization method based on a multi-source data fusion model, used in a terminal. The processing flow of this method may include the following steps:

[0045] S1: The terminal collects continuously sampled data at a fixed sampling period: vehicle operation status data, vehicle control and operation status data, and relative status data between the vehicle and forward targets. Vehicle operation status data characterizes the vehicle's longitudinal movement, including at least vehicle speed, longitudinal acceleration or deceleration, and braking signals. Braking signals can be one or more of brake switch quantity, brake pedal opening, or brake pressure. Vehicle control and operation status data characterizes station behaviors and lane-changing behaviors strongly related to public transport operation rules, including at least door status and turn signal status. Relative status data between the vehicle and forward targets characterizes following distance and potential collision risks, including at least one or more of headway, distance, and relative speed. Simultaneously, the terminal collects active safety warning event data, including at least forward collision warnings, sudden deceleration events, and driver distraction-related warning events. These four types of data are used together for subsequent risk assessment and execution gating of candidate dispatch actions.

[0046] To avoid misjudgments of time semantics caused by cellular network latency fluctuations, the terminal uses the "sampling occurrence timestamp" as the primary time field and writes the continuous sampling sequence into a circular buffer. For alarm events, the terminal records their trigger timestamp, level, and duration, and maps alarm events to the corresponding sampling index according to their trigger timestamp, forming a local data stream sorted by the primary time field. The alarm event reporting arrival time is only stored as a network transmission statistics field and is not used as the primary time basis for fusion analysis.

[0047] S2: The terminal segments the operational status according to the semantics of bus operation events. Among them, the semantics of bus operation events include at least station-related semantics and non-station semantics.

[0048] Site-related semantics include at least one or more of the following: inbound semantics, stop semantics, and outbound semantics.

[0049] The semantics of vehicle entry into a station are triggered by both the vehicle entering the station's proximity state and the vehicle speed entering a decreasing trend. Specifically, the vehicle is determined to be in the station's proximity state when the distance between the vehicle and the target station changes from being greater than a preset proximity distance threshold to being less than or equal to the preset proximity distance threshold. This proximity state characterizes the preset geographical range surrounding the target station, preventing deceleration or temporary stops at non-station locations from being mistakenly identified as entry or stop. The preset geographical range can be configured by the operator or obtained based on historical trajectory statistics. For example, it can be calculated by statistically analyzing the distance distribution from the location of the first significant deceleration before the vehicle enters the station to the station coordinates, taking the quantile as the proximity radius, and can be set and updated tiered by route / station type. The decreasing speed trend characterizes the vehicle starting to decelerate and approach the station, and this decreasing trend can be determined by judging the vehicle speed changes over several consecutive sampling periods. That is, when the vehicle speed continuously decreases within a continuous sampling period, and the magnitude or rate of decrease reaches a preset decreasing trend threshold, the vehicle speed is determined to be entering a decreasing trend. The preset trend threshold (declining / rising trend) can be calibrated from historical steady-state data or set empirically. In this embodiment, the terminal calculates the rate of change or difference component of the velocity sequence within a short time window. When the rate of change is less than the declining threshold, it is determined to be a declining trend; when it is greater than the rising threshold, it is determined to be an rising trend.

[0050] The station stop semantics satisfy the condition that the door is open for a preset duration. The preset duration can be the minimum door opening confirmation duration or adaptively determined based on the historical station stop duration statistics for each station / time period. The station exit semantics satisfy the condition that the vehicle speed enters an upward trend after the door is closed and continues to reach the preset duration. When an upward trend in vehicle speed is detected within the preset duration after the door is closed, the station exit semantics are determined. If the upward trend in vehicle speed is interrupted by external constraints such as red light stops or traffic congestion ahead within the preset duration, a fault-tolerant strategy can be adopted: the vehicle leaving the vicinity of the station or the vehicle position continuously displacing along the line direction to reach a preset displacement threshold can be used as an alternative judgment condition, so that the station exit semantics can still be identified.

[0051] Non-station semantics include at least one or more of the following: cruise semantics, section operation semantics, close following semantics, or lane change / change semantics. Cruise semantics satisfies the condition that the vehicle speed fluctuation amplitude is lower than a preset fluctuation threshold and the door remains closed, and the vehicle speed fluctuation amplitude can be calculated from the range, standard deviation, or quantile difference of the speed sequence within the cruise window. Section operation semantics satisfies the condition that the vehicle position is between adjacent stations and the distance to the nearest station is greater than a preset proximity distance threshold, the door remains closed, the vehicle speed is greater than a preset minimum vehicle speed threshold, and the above conditions continue for a preset duration. Close following semantics satisfies the condition that a forward target is detected and the headway is less than a preset tension threshold or the collision time is less than a preset risk threshold, the door remains closed, and the tension state continues for a preset duration. Lane change / change semantics satisfies the condition that the turn signal is on or the turn operation is triggered, and the lateral movement characteristics satisfy preset conditions, including one or more of the following: lateral acceleration exceeds a threshold, heading angle change rate exceeds a threshold, or lane deviation change exceeds a threshold, and the door remains closed for a preset duration. Lateral acceleration and rate of change of heading angle can be acquired by inertial measurement unit, and lane offset can be estimated by lane line recognition or positioning map matching; under different vehicle configurations, the above quantities can be selectively enabled and used as missing markers in the determination.

[0052] Within a segment, the terminal calculates a segment execution summary online, which includes at least a longitudinal response statistics summary and an alarm event summary.

[0053] The longitudinal response statistical summary is used to characterize the vehicle's longitudinal driving response and rhythm stability. The longitudinal response statistical summary includes at least the following statistics: rapid deceleration event rate, acceleration quantile statistics, speed fluctuation statistics, and the proportion of headway tension.

[0054] The rapid deceleration event rate characterizes the frequency of significant deceleration events occurring within a given operating segment. This indicator directly reflects whether dispatching actions or changes in the operating environment induce emergency braking by the driver, serving as a crucial early warning indicator for active safety warnings and deterioration of ride comfort. Relying solely on average deceleration or single-point extreme values ​​is insufficient to reflect the frequency characteristics of this type of risk. Acceleration quantile statistics characterize the overall intensity level of the vehicle's longitudinal acceleration and deceleration distribution. By statistically analyzing the high quantile values ​​of the acceleration sequence, such as the 90th quantile, it avoids the excessive influence of single outliers on the judgment results. Simultaneously, it reflects whether dispatching actions have overall increased the intensity of longitudinal driving control, providing a basis for distinguishing between "occasional anomalies" and "systematic disturbances." Speed ​​fluctuation statistics reflect the stability of the vehicle's operating rhythm within a segment. Excessive speed fluctuations usually indicate frequent corrections in driving operations or that the dispatching strategy has introduced rhythm discontinuities. Such fluctuations directly affect arrival time prediction and interval running time estimation, and are a significant source of background deviation jitter. The headway tension ratio characterizes the proportion of time a vehicle is under high following pressure within a segment. This indicator reflects whether dispatching actions cause the vehicle to be in a following state with insufficient safety margin for an extended period. It is a key indicator for assessing whether costly and disruptive actions such as stop-and-go, short-line turnaround, strong follow-up point prompts, and end-of-line dispatching introduce potential safety risks. By including at least the above statistics, the longitudinal response statistical summary can structurally characterize the driving longitudinal response from four dimensions: frequency, intensity, stability, and safety margin, without relying on high-frequency raw data.

[0055] Alarm event summaries are used to characterize alarm clustering features, and may include alarm counts by type, alarm duration statistics, number of alarm clusters, or alarm cluster density.

[0056] For example: if vehicle A experiences two rapid deceleration intervals within a 30-second cruising segment, the rapid deceleration event rate is approximately 0.067 times / second (2 / 30 ≈ 0.067). If the headway is less than 1.2 seconds for a cumulative total of 12 seconds, the tension ratio is approximately 0.40 (12 / 30 ≈ 0.40). The speed standard deviation of 4.8 km / h is used as the speed fluctuation indicator. If alarms are clustered into two clusters, the alarm cluster density is approximately 0.067 clusters / second (2 / 30 ≈ 0.067). Simultaneously, the longitudinal acceleration sequence is sorted from smallest to largest, and the 90th percentile value P90(a) is used as the acceleration quantile statistic.

[0057] If there are 3 distraction alarms and 1 collision warning within a segment, the alarm count by type is {Distraction: 3, Collision: 1}. If the two alarm clusters last for 5 seconds and 7 seconds respectively, the alarm duration is counted as 12 seconds (or summarized by type). If two alarm clusters are obtained after clustering according to the alarm clustering time interval threshold, the number of alarm clusters is 2, and the alarm cluster density is 2 / 30. The alarm clustering time interval threshold is used to determine whether adjacent alarms belong to the same alarm cluster.

[0058] In this embodiment, in order to enable the cloud platform to maintain the consistency of scheduling decisions under conditions such as concurrent arrival of multiple versions of evidence, link latency fluctuations, and re-estimation of terminal fragment boundaries, the terminal generates versioned evidence after generating the fragment running summary.

[0059] Versioned evidence includes at least an evidence version number and a versioned evidence payload; the evidence version number is generated by a combination of fragment identifier, fragment boundary summary, summary caliber identifier and generation time sequence identifier; the versioned evidence payload includes at least a fragment execution summary and an event mapping summary corresponding to the fragment execution summary.

[0060] The segment boundary defines the start and end range of a runtime state segment within the terminal's local data stream. It includes at least a start boundary and an end boundary, which can be represented by a sampling timestamp or sampling index. The segment boundary summary is a summary of the segment boundaries, including at least a compressed summary of the start and end boundaries. This reduces reporting and comparison overhead while providing a consistent representation of the segment's start and end range, supporting stable generation of evidence version numbers and consistent processing on the cloud platform. The segment identifier uniquely identifies the runtime state segment. It is generated by combining at least the vehicle or terminal identifier, the public transport operation event semantic type identifier, the segment boundary summary, and / or a locally incrementing sequence number. This supports segment summary reporting, cloud platform aggregation, and command binding. The locally incrementing sequence number is a monotonically increasing number generated and maintained by the terminal on its local machine. It is used to sequentially number newly generated runtime state segments or evidence versions, ensuring differentiation on the terminal side, avoiding duplicate names, and facilitating binding and deduplication. An event mapping summary describes the correspondence between alarm events and continuously sampled data within a segment. It includes at least the alarm event's identifier, alarm type information, and mapping information indicating the alarm's corresponding position within the segment. This mapping information can be represented as a summary of time or sequence position. The event mapping summary can be reported along with the segment execution summary to support alarm attribution and consistency processing on the cloud platform.

[0061] During implementation, any of the following changes will alter the cloud platform's comparability criteria for the same operational fact: When a fragment boundary triggers reassessment, the start and end ranges of the fragment in the local data stream change, and the statistical window corresponding to the fragment's operational summary changes accordingly. To avoid summaries with different start and end ranges being mistakenly identified as the same evidence, a new version number is needed to distinguish them. When the alarm attribution index is updated, the position of the alarm event within a fragment or its corresponding fragment attribution changes, altering the correspondence between the event mapping summary and the fragment's operational summary. To prevent changes in alarm attribution from causing cloud-based decisions to misuse old mappings, a new version number is needed to distinguish them. The version number identifies the updated evidence. When statistical dimensions, sampling periods, or binning rules are updated, the statistical caliber for summary calculation changes. Even if the original data remains unchanged, the meaning and scale of summary fields may differ. To ensure that cloud-based consistency judgments and risk assessments are conducted only under the same caliber, it is necessary to distinguish evidence with different calibers using the new version number. When a summary changes from a missing marker to a valid marker, the evidence coverage or the completeness of key fields changes, and the summary changes from partial information to complete information. To prevent the cloud from mixing the completed valid summary with the previously missing summary as the same evidence, it is necessary to clarify its updated availability status through the new version number. Therefore, this embodiment generates a new evidence version number and binds it to the new versioned evidence payload for reporting when any of the following conditions are met: fragment boundary triggers reassessment, alarm attribution index is updated, statistical dimensions, sampling periods, or binning rules are updated, or the summary changes from a missing marker to a valid marker. Meanwhile, the type of versioned evidence includes at least one or more of the following: boundary version, attribution version, caliber version, or integrity version. Boundary version characterizes the re-evaluation status of the start and end positions of the same segment; attribution version characterizes the attribution change after an alarm event is aligned to a sampling index; caliber version characterizes the change in the calculation caliber of the statistical summary; and integrity version characterizes the change in evidence coverage caused by delayed re-transmission. Specifically, the re-evaluation status of the boundary version refers to the re-determination of the start and / or end boundaries of the running state segment during subsequent data completion, outlier correction, or boundary determination updates; the attribution change of the attribution version occurs when the same alarm event is mapped to different sampling indices or different running segments after timestamp alignment or index alignment, resulting in a change in its assigned segment; the caliber change of the caliber version occurs when the statistical caliber of the segment's running summary is adjusted, such as changes in statistical dimensions, sampling period, resampling method, or binning rules; and the coverage change of the integrity version occurs when, due to delayed re-transmission or batch reporting, the segment summary changes from a missing marker to a valid marker, or key fields within the segment change from partially missing to meeting preset integrity conditions, which can be obtained from historical data.

[0062] After the terminal segments the operation status into segments according to the semantics of bus operation events and generates versioned evidence, the terminal will report the segment summary, which includes at least the segment identifier, segment boundary, evidence version number and segment operation summary, to the cloud platform. This will enable the cloud platform to complete the consistency determination and two-stage distribution control when it only obtains the summary layer evidence, and avoid the risk score and gating conclusions from being frequently flipped in adjacent decision-making cycles due to the mixing of different versions of evidence.

[0063] S3: The terminal receives the scheduling instructions issued by the cloud platform and parses and registers them. After receiving the segment summary reported by the terminal, the cloud platform aggregates the evidence version number according to "vehicle identifier + segment identifier" and performs evidence version consistency judgment, comparing the evidence version numbers received for the same segment within the current decision cycle. If the version number is unique and remains unchanged, the evidence is determined to be consistent; if the version number has multiple values ​​or changes (corresponding to changes in segment boundary summary / summary caliber identifier), the evidence is determined to be inconsistent. If inconsistent evidence is detected for the same segment, an observation or freezing strategy is triggered to restrict strong actions from entering the submission state; if the evidence is consistent, a set of candidate scheduling actions is generated, and intensity levels and effective windows are configured for the candidate actions. In this embodiment, intensity levels and effective windows are used to parameterize the intervention intensity and effective range of candidate scheduling actions. Among them, intensity levels are used to characterize the intervention intensity level of candidate scheduling actions, including at least low, medium, and high levels, which can be selected according to deviation amplitude, alarm aggregation degree, etc. If the evidence fluctuates greatly, a lower level can be configured or downgraded to a low-disturbance action. The effective window is used to limit the scope of an action on the terminal side, and can be represented in the form of a time window, distance window, segment window, or site window. When the evidence fluctuates greatly, the effective window can be shortened to reduce the exposure time of strong actions and cascading disturbances.

[0064] The cloud platform generates two-stage scheduling instructions and sets instruction sequence numbers. These sequence numbers can be generated using any of the following methods: Globally incrementing sequence number: The cloud platform maintains a monotonically increasing counter for the same vehicle or the same "vehicle identifier + fragment identifier" dimension, incrementing the counter by 1 for each scheduling instruction generated; Timestamp-type sequence number: The instruction generation timestamp is used as the main field, overlaid with a random number / auto-incrementing tail number to avoid conflicts with the same millisecond; Combined coded sequence number: Obtained by combining and encoding the vehicle identifier, fragment identifier, evidence version number digest, and generation time sequence identifier. Simultaneously, when issuing instructions, the cloud platform binds the instruction sequence number and the evidence version number and writes them into the instruction field.

[0065] The two-stage scheduling instructions include: preparatory state instructions and commit state instructions. Preparatory state instructions are low-disturbance actions such as minor stops, prompts, mild speed control suggestions, and extended observation, carrying a cancellation window parameter; commit state instructions are strong actions and are issued when the commit conditions are met. The commit conditions are used to determine whether the preparatory state execution result and the updated evidence meet the requirements for strong action release, including at least one or more of the following: evidence version consistency, gating conclusion meeting the release requirements, and no cancellation / freeze control being triggered.

[0066] S4: After receiving the scheduling instruction, the terminal performs data processing based on the instruction sequence number and evidence version number, and executes according to a two-stage mechanism of preparatory state and submission state: Preparatory state: The terminal executes a low-disturbance action and opens a cancellation window, continuously transmitting an execution state summary within the cancellation window; cancellation or rollback of the low-disturbance action is allowed within the cancellation window. Submission state: The terminal executes a strong action and sets an irreversible threshold during the execution of the strong action; when the strong action reaches the irreversible threshold, cancellation is prohibited and only compensation actions are allowed, and an execution evidence summary is transmitted back. In this embodiment, the irreversible threshold is used to identify the critical point where cancellation during the execution of a strong action will produce inconsistencies or security risks, and it can be represented in the form of a threshold or event condition. The terminal can configure corresponding irreversible judgment conditions based on the type of strong action: for example, when the strong action has been continuously executed for a preset duration (which can be obtained from historical data), has crossed a preset station / segment boundary, has completed the issuance of key control quantities and been confirmed as effective by the actuator, or has generated a state change that cannot be recovered within the cancellation window, the strong action is determined to have reached the irreversible threshold. Once the terminal hits the irreversible threshold, the strong action is prohibited from being revoked; only compensatory actions are allowed to reduce disturbances or restore the terminal to the scope of the security policy. The execution state summary may include fragment execution summary increments, alarm cluster density changes, fragment boundary changes, or execution restriction states, etc. In this embodiment, the execution state summary and execution evidence summary are automatically generated locally by the terminal. During the execution of scheduling instructions, the terminal forms and sends back summary information based on local continuous sampling data, alarm event statistics, fragment segmentation results, and instruction execution status. The aforementioned fragment execution summary increments, alarm cluster density changes, fragment boundary changes, and execution restriction states can all be obtained by comparing the pre-execution baseline summary with the in-execution / post-execution summary; the terminal only sends back increments or key markers to reduce communication overhead and facilitate cloud platform review and deduplication.

[0067] Through the above operations, this embodiment can successfully solve the coupling problem of end-to-cloud collaborative bus scheduling. For example, under the conditions of out-of-order / delay in cellular networks, the segment boundary may be re-estimated, the alarm attribution may drift, and strong actions may cause reverse disturbances to the prediction deviation. At the same time, the present invention reduces the risk of repeated issuance, revocation bounce and execution inconsistency by using evidence version consistency, two-stage instructions, irreversibility threshold and controlled closed loop of execution evidence return.

[0068] Embodiment 2 of the present invention: Based on Embodiment 1, this embodiment further provides a method for evidence purification and stability assessment of the cloud platform under the condition that "evidence version consistency is determined to be consistent", so as to reduce the back-end decision reversal caused by delayed data, such as fragment boundary re-estimation, alarm attribution drift and statistical caliber fluctuation in the cloud collaboration scenario of public transportation.

[0069] After receiving the fragment summary, the cloud platform performs alarm availability discrimination and aggregation measurement on the alarm event summary and event mapping summary within the fragment to obtain purified alarm evidence.

[0070] Alarm clustering metrics are used to distinguish between sporadic, discrete alarms and persistent, clustered alarms. In this embodiment of the invention, the cloud platform performs time-interval-based clustering based on alarm trigger time series: adjacent alarms are grouped into the same alarm cluster if they meet preset clustering criteria. The clustering criteria include at least: the trigger time interval between adjacent alarms does not exceed a preset clustering interval threshold, which can be obtained from historical data; adjacent alarms are consistent or similar in alarm type or alarm source; and adjacent alarms belong to the same running state segment or the same semantic window. After clustering, the cloud platform obtains the number of alarm clusters and constructs the alarm cluster density by dividing the number of alarm clusters by the segment duration.

[0071] Alarm availability assessment is used to suppress false triggering of distraction / collision warning alarms due to high-frequency driving behaviors in bus scenarios, such as observing at bus stops, scanning before and after stops, and lane-changing avoidance. The cloud platform constructs scene consistency markers based on bus operation event semantics. When an alarm occurs within a preset buffer zone of a semantic window such as the stop / entry / exit window or the lane-changing / lane-changing window, the alarm is marked as scene-confusing; otherwise, it is marked as scene-consistent. And combined with the duration of the alarm Alarm Level Calculate alarm availability score The alarm availability score is a normalized score, ranging from 0 to 1. A value closer to 1 indicates a more reliable alarm and suitability for scheduling decisions, while a value closer to 0 indicates the alarm is more likely to be affected by easily confused factors in the scenario and should have its weight reduced or be used only for observation. The alarm level is determined by the active safety algorithm based on a mapping between the corresponding risk indicator, such as TTC / vehicle headway or distraction duration, and a preset threshold range when the alarm is triggered. Higher risks result in higher alarm levels, and the alarm is reported to the cloud platform along with the alarm event. The alarm duration is the difference between the start and end timestamps carried in the alarm event report, or it can be calculated by converting the difference between the first and last trigger timestamps of consecutive triggers / the number of trigger frames and the frame period.

[0072] For example: ;where clip(x, 0, 1) is the cutoff function, which restricts the input x to the interval [0, 1], taking 0 if it is below 0 and 1 if it is above 1; This is an indicator function that takes the value 1 if the condition within the parentheses is true, and 0 otherwise. The weight coefficients for each factor in the alarm availability score can be preset parameters or parameters obtained from training / calibration; i is the alarm data number; The normalization function is monotonically increasing. In one implementation, it can be achieved using piecewise linear normalization, saturation normalization, or normalization based on historical quantiles.

[0073] The cloud platform will Mapping to high / medium / low availability and calculating the proportion, forming cleanup alarm evidence {alarm density, high / medium / low availability proportion}.

[0074] To suppress short-term counter-disturbance fluctuations caused by strong actions in arrival prediction deviations, interval running time deviations, and train interval deviations, this embodiment performs persistence determination or multi-vehicle consistency determination on the evidence of operational deviations and outputs anomaly confidence levels. Taking interval running time deviation as an example, the cloud platform calculates the deviation residuals of the same road segment over L consecutive decision cycles. Calculate the persistence ratio P:

[0075] ;

[0076] in, The deviation residual value corresponding to the k-th decision period is the observation runtime minus the baseline prediction runtime, and k The observation runtime is calculated as the difference between the semantic endpoint time of the first station and the semantic starting time of the next station, or the difference between the threshold crossing times of adjacent stations. The baseline prediction duration can be obtained from historical steady-state statistics of the same line, section, and time period on the same workday, and then rolled over and corrected in conjunction with the observation results of the most recent several periods. k is the decision cycle or rolling window number, which increases sequentially. L is the number of consecutive periods (window length) used for persistence determination, and L is set to a positive integer based on the ratio of the persistence time window to the decision cycle. The persistence time window is determined according to the type of deviation object, such as section / arrival / shift interval. The decision cycle can be understood as the fixed beat of the cloud platform "refreshing the scheduling decision / risk control gating once", for example, every 10s / 15s / 30s. This is an indicator function that takes the value 1 if the condition within the parentheses is true, and 0 otherwise. The threshold for the deviation residual amplitude can be set based on historical experience. The study concluded that the deviation was "significant" during this period.

[0077] Because bus operation data, under edge-cloud collaborative conditions, is susceptible to factors such as location drift, false alarm triggering, and re-estimation of segment boundaries due to delayed retransmission, deviations observed by a single vehicle may be caused by individual driver operations, temporary avoidance, individual vehicle malfunctions, or fluctuations in single-vehicle data quality, making it difficult to directly characterize changes in road segment-level operational status. Meanwhile, external environmental issues such as road congestion, signal control anomalies, and road construction often exhibit consistent deviation characteristics across multiple vehicles within the same road segment and time window. Based on this, the cloud platform calculates the consistency ratio C among multiple vehicles within the same road segment and time window:

[0078] ;

[0079] Where Ω represents the set of neighboring vehicles on the same road segment / within the same time window, i.e., a group of vehicles used for consistency comparison. Its composition can be determined based on the route, section, time window, and spatial proximity. |Ω| represents the number of vehicles in set Ω. Let be the residual value of vehicle v in the k-th decision period.

[0080] The cloud platform combines the persistence ratio P and the multi-vehicle consistency ratio C, and overlays the hit flag h during the cooling period (which lowers the confidence level upon hit) to obtain the anomaly confidence level q. , of which For the Sigmoid function or equivalent mapping, where, The Sigmoid mapping parameter can be calibrated offline using historical operational data or preset by engineers and updated based on post-launch review logs. For the value of h, h=1 if any of the following events occur within the recent cooldown period of the current segment or road segment: the terminal executes a strong commit action or an irreversible threshold hit occurs; the evidence version undergoes a boundary version update (segment boundary reassessment) or an attribution version update (alarm attribution drift); a statistical caliber switch or delayed retransmission causes the integrity version to change from missing to valid; otherwise, h=0. The cooldown period length can be set as an integer multiple of the cloud platform's decision cycle and can be set according to the type of deviation object.

[0081] In this embodiment, the calculation framework for persistence determination / multi-vehicle consistency determination can be reused for different deviation objects. The difference lies in the definition of deviation residuals, the acquisition caliber of observations, and the composition of the neighborhood vehicle set Ω. Except for interval running time deviation, when the deviation object is arrival prediction deviation, the deviation residual corresponding to the k-th decision period is defined as the difference between the arrival observation time and the arrival baseline prediction time. The arrival observation time can be the crossing time of a vehicle entering the vicinity of a station, or the trigger time that satisfies the semantic starting point condition for entering the station. The arrival baseline prediction time can be obtained from historical steady-state statistics of the same route, station, workday type, and time period, and then rolled over with the observation results of the most recent several periods. Correspondingly, the calculation method for persistence ratio P and multi-vehicle consistency ratio C is consistent with that for interval running time deviation, only replacing the deviation residual value with the arrival prediction residual. Ω can be selected from multiple vehicles on the same route, at the same station, and within the same time window that are in close station spacing intervals to form a neighborhood vehicle set, thus characterizing the consistency of station-level operational status changes. When the deviation is the frequency interval deviation, the deviation residual corresponding to the k-th decision period is defined as the difference between the observed frequency interval and the baseline predicted frequency interval. The observed frequency interval can be the arrival or departure time difference between two adjacent frequency trains at the same station, and the baseline predicted frequency interval can be obtained from the planned timetable / historical steady-state interval statistics and continuously corrected. Correspondingly, Ω can be a set of adjacent trains on the same line at the same station or the same key section, or a set of trains that can form a continuous fleet sequence within the same time window, to characterize the consistency of the frequency interval fluctuation at the line level.

[0082] Therefore, the arrival prediction deviation, interval running time deviation, and train interval deviation can be mapped using a combination of the same persistence ratio P, multi-vehicle consistency ratio C, and cooldown period hit marker h to obtain the anomaly confidence level q. However, their threshold parameters (e.g., deviation residual amplitude threshold, persistence window length L, and cooldown period length) can be set according to the deviation object type: longer persistence time windows and cooldown periods can be used for arrival prediction deviation and train interval deviation to cover the propagation range of strong actions on rhythm disturbances; shorter windows can be used for interval running time deviation to maintain response sensitivity. This yields the purified deviation evidence {q, h}.

[0083] The cloud platform further performs a stability assessment on consistent evidence to adjust the intensity level or effective window of candidate actions, or trigger a downgrade to a low-disturbance action.

[0084] Fragment boundary drift: adjacent evidence versions of the same fragment and Extract the start and end boundaries of each segment. and Construct fragment boundary drift : And can be normalized to the fragment length as .

[0085] Where n is the version number index. The start and end boundaries of a segment are the start and end positions of the running state segment. These boundaries can be represented by timestamps or sampling indices and can be re-estimated as the evidence version is updated when delayed data is retransmitted or anomaly corrections are triggered. That is... , These are the start and end points of the old version segment, respectively. These represent the start and end points of the new version segment, respectively.

[0086] Alarm attribution drift: The alarm mapping index set is obtained based on the event mapping digest. Construct the attribution consistency and use its complement as the alarm attribution drift: ;

[0087] In calculating alarm attribution drift, to avoid numerical instability caused by a denominator of 0 or too small a value, a stabilization term ε is introduced into the denominator of attribution consistency, such as Jaccard consistency. ε is a preset, extremely small positive number used to maintain the definitionability and stability of the calculation results when the union of sets is empty or the sample size is very small.

[0088] Abstract Statistical Fluctuation Amplitude: A vector is formed from key statistics in the segment runtime summary, such as the rate of rapid deceleration events, speed fluctuation statistics, the proportion of tight headway, and alarm cluster density. Construct the fluctuation range of the normalized summary statistic: ;

[0089] Where j is the index of the statistical dimension, for example j=1 corresponds to "rapid deceleration event rate", j=2 corresponds to "speed fluctuation statistics", j=3 corresponds to "proportion of tight headway", and j=4 corresponds to "alarm cluster density". J is the total number of statistical dimensions, and in this embodiment J=4. Estimate the scaling parameter of the j-th statistic on historical steady-state data of the same line / semantic type. To characterize the change in summary statistics of the same fragment under adjacent evidence versions (or adjacent decision cycles), each statistic is subtracted from the current summary and the previous summary in each dimension, and then normalized and summarized according to historical steady-state scale to characterize the fluctuation range of summary statistics.

[0090] The cloud platform determines a stability level based on the fragment boundary drift, alarm attribution drift, and summary statistics fluctuation. When any drift / fluctuation exceeds the threshold, it is determined to be unstable. Then, one or a combination of the following adjustment strategies are executed on the candidate action set: downgrade the strong action level from high / medium to low; shorten the effective window from the original setting to within the safe upper limit to reduce the exposure time of strong actions; directly trigger the downgrade to a low-disturbance action, and only allow entry into the preparatory state strategy.

[0091] Low-disturbance actions refer to terminal-side execution strategies that do not change the station sequence, route path, or trigger stop or turnaround, such as: prompts (point-following prompts, rhythm prompts), mild speed control suggestions (target speed limit or acceleration / deceleration smoothing suggestions), extended observation (only extending the evidence window and sending back the summary), micro-stop / micro-release (making minor adjustments to the departure time within the station and subject to the cancellation window), etc.

[0092] Embodiment 3 of the present invention: Based on the evidence purification and stability assessment of Embodiment 2, this embodiment further provides a method for the cloud platform to perform pre-action risk assessment and threshold range gating for candidate scheduling actions, in order to solve the coupling problem of frequent reversal and revocation of gating conclusions caused by strong action anti-disturbance in the cloud collaboration scenario of public transportation.

[0093] The cloud platform conducts a risk assessment for each candidate scheduling action. Each candidate scheduling action must include at least the action type, intensity level, and effective window information. The cloud platform constructs a corresponding risk assessment feature set for each candidate scheduling action, which includes at least one or more of the following: First category: Segment operation summary features: Vertical response statistical features and alarm event statistical features obtained from the segment operation summary, including at least the rapid deceleration event rate, speed fluctuation statistics, headway tension ratio, alarm cluster density, and station dwell time deviation. Second category: Evidence stability features: Evidence stability features obtained from evidence version consistency determination, including at least segment boundary reassessment markers, alarm attribution drift, evidence version drift, and arrival out-of-order intensity. Arrival out-of-order intensity can be quantified using the proportion of delayed data or out-of-order arrivals in one implementation. Evidence version drift can be quantified using the number of evidence version number changes or the magnitude of key summary field changes per unit time in one implementation. The third type of action intensity profile features, derived from candidate scheduling actions, their intensity levels, and effective windows, includes at least the action type, coding intensity, level mapping value, effective window length, disturbance sensitivity, and disturbance cost indicator. The disturbance cost indicator can be obtained by mapping action levels to effective windows; for example, a higher base cost is set for strong actions, increasing monotonically with the level, and a longer effective window corresponds to a higher cost. The fourth type of anti-disturbance prediction deviation index is used to characterize the degree of reverse disturbance of candidate strong actions on arrival prediction deviation, interval running time deviation, and shift interval deviation, thereby enabling risk assessment to simultaneously characterize the risk of evidence instability and the risk of strong action anti-disturbance.

[0094] To avoid relying solely on subjective definitions of anti-disturbance risks based on experience, this embodiment constructs an anti-disturbance prediction bias index using observable residual changes between the baseline window and the effective window. In one implementation, the cloud platform establishes a baseline prediction for the same vehicle and the same semantic segment, forming a residual sequence. The residual sequence can be selected as one of the following: arrival prediction bias residual, interval running time bias residual, or shift interval bias residual. The cloud platform selects the adjacent steady-state window before the segment as the baseline window. The baseline window satisfies the condition that no strong actions of the same type have been applied and the consistency of evidence versions is stable, thus characterizing the normal fluctuation level. The cloud platform also extracts the effective window of the same type of action in similar semantic segments from historical execution receipts, thus characterizing the fluctuation level after the action is introduced. The cloud platform uses the increment of the residual fluctuation intensity of the effective window relative to the residual fluctuation intensity of the baseline window as the anti-disturbance prediction bias index; the larger the increment, the stronger the anti-disturbance. This approach aligns with the physical logic of the public transportation scenario: the stronger the strong action, the longer the effective window, and the more intense the execution, the more likely it is to disrupt the vehicle's rhythm and lead to increased prediction bias fluctuations.

[0095] The cloud platform outputs risk scores for candidate scheduling actions based on the aforementioned risk assessment feature set. In one possible implementation, the risk score employs a monotonically consistent combination mapping to ensure consistency with engineering intuition: that is, the higher the alarm cluster density, the more unstable the evidence, the stronger the action, and the greater the anti-disturbance deviation increment, the higher the risk score.

[0096] The cloud platform sets an allowance threshold and a rejection threshold to form a threshold range, and performs range gating accordingly, including at least the following strategies: When the risk score meets the allowance condition: the candidate scheduling action is allowed to enter the preparatory state and has the qualification to be submitted; when the risk score meets the rejection condition: the candidate scheduling action is rejected or downgraded to a low-disturbance action; when the risk score is between the allowance threshold and the rejection threshold: it is judged as a gray zone action, only allowed to enter the preparatory state, and the evidence window is extended to trigger a rolling re-determination to suppress gating jitter caused by delayed data backfilling, alarm attribution drift, and fragment boundary re-estimation. The allowance condition is that the risk score is lower than the allowance threshold, and the consistency of the evidence meets the preset requirements, such as stable fragment boundaries, stable alarm attribution, unchanged or changed summary caliber within the allowable range, and the intensity and effective window of the candidate action are within a safe and controllable range. The rejection criteria are: a risk score exceeding the rejection threshold, or evidence consistency failing to meet preset requirements, such as frequent reassessment of fragment boundaries, significant alarm attribution drift, excessive fluctuations in statistical summaries, or severe out-of-order arrival of data, or the candidate action potentially causing unacceptable disturbances and security risks under current conditions. Both the approval and rejection thresholds mentioned above can be obtained from historical data.

[0097] When a candidate scheduling action is determined to be a gray zone action, the cloud platform extends the evidence window and triggers a rolling re-determination. The rolling re-determination includes at least the following process: within the extended evidence window, continuously acquiring the execution state summary and updated fragment execution summary returned by the terminal, re-executing the evidence version consistency determination, and updating the evidence stability features, as well as the execution features and alarm features related to the fragment execution summary, thereby updating the risk score. If the updated risk score meets the release conditions in at least a certain number of consecutive rolling re-determinations, and the evidence version consistency continuously meets the stability condition, then a strong submission action is allowed. The number of consecutive determinations can be set according to the ratio of the decision cycle to the duration window, and can be set according to the semantic type of the deviation. For example, a longer duration window can be used for interval runtime deviation, a medium duration window for arrival prediction deviation, and a duration window covering at least one shift interval for shift interval deviation, to ensure that the release conclusion is insensitive to short-term noise. When any rolling decision meets the rejection condition, or the consistency of the evidence version becomes unstable, the candidate scheduling action is rejected or downgraded to a low-disturbance action to avoid amplifying disturbances with strong actions under unstable evidence conditions. When the number of times the gating conclusion is flipped in adjacent decision cycles for the same segment reaches a preset limit, or the gray zone dwell time exceeds a preset limit, a freeze window is triggered. Within the freeze window, strong actions in the submission state are prohibited, and only low-disturbance actions in the preparatory state are allowed to suppress background errors and strategy jitter. The cloud platform generates a gating reason summary when rejecting, downgrading, or triggering the freeze window, and stores the gating reason summary in association with the corresponding evidence version number. The gating reason summary includes at least: the dominant risk factor identifier, the corresponding evidence version number, and the threshold exceedance magnitude or change direction of the dominant risk factor. In one implementation, the dominant risk factor identifier may include: increased boundary drift, increased attribution drift, increased alarm cluster density, increased anti-disturbance deviation, increased arrival disorder intensity, etc., for terminal-side execution restriction prompts and cloud platform-side review and calibration.

[0098] Embodiment 4 of the present invention: Based on Embodiment 1 or Embodiment 2 and Embodiment 3, this embodiment further provides an implementation method for adaptive adjustment of cloud platform side parameters, so as to suppress background errors caused by repeated distribution, cancellation back-end and gating flip in the bus scenario where cellular network latency fluctuations, delayed data backfilling and strategy two-stage execution coexist, and improve the reviewability and calibrability of scheduling strategies.

[0099] During the execution of preparatory and submit instructions, the terminal, in addition to sending back the execution state summary, also sends back the execution evidence summary. The segment summary, execution state summary, and execution evidence summary are then encapsulated and reported after being associated with the segment identifier, evidence version number, and instruction sequence number. Specifically: The execution state summary characterizes the phased execution status of the instruction on the terminal side, including at least whether the preparatory state is effective, the remaining duration of the cancellation window, and the terminal's current execution restrictions (e.g., only prompting / only speed control suggestion / only extended observation), used by the cloud platform to determine whether the instruction has entered an irreversible stage. The execution evidence summary characterizes the key execution receipt evidence on the terminal side, including at least the instruction sequence number, instruction stage identifier (preparatory or submit), execution confirmation timestamp or sampling index, irreversible threshold hit marker, and a brief execution result code (e.g., successful execution / cancelled / downgraded / compensated), used by the cloud platform for traceable closed-loop management of the instruction lifecycle. After receiving the aforementioned related feedback information, the cloud platform aggregates the information into evidence packages according to the segment identifiers, and establishes a related index within the evidence package using "evidence version number + instruction sequence number" as the key, thereby ensuring that different evidence versions of the same segment and different stages of the same instruction can be correctly merged in the background.

[0100] The cloud platform calculates a set of backend error indicators within the evidence package using a rolling statistical window, such as the most recent decision-making cycles or the most recent minutes. For ease of implementation, the following are examples of operable calculation methods for various indicators: **Duplicate Issuance Rate:** Within the statistical window, for the same segment identifier and the same evidence version number, if multiple instructions with different sequence numbers but the same action type and target, and the issuance time interval is less than the preset minimum interval, are counted as duplicate issuance. The duplicate issuance rate can be calculated as "number of duplicate issuances / total number of issuances". **Cancellation Rebound Rate:** Within the statistical window, for instructions entering the preparatory state, if cancellation occurs within the cancellation window and a similar or opposite instruction is issued again within a short period after cancellation (e.g., first prompting for tracking, then cancellation and then prompting for speed reduction, or first lightly controlling speed, then cancellation and then lightly controlling speed again), this is counted as cancellation rebound. The cancellation rebound rate can be calculated as "number of cancellation rebounds / number of preparatory state instructions". Gating Flip Count: For the same candidate action or similar action within the same segment, the number of times the gating conclusion switches back and forth between release, gray zone, and rejection within adjacent decision cycles is counted as the gating flip count. It can also be further normalized to "flip count per unit time" for comparison between different routes or different trains. Conflict Command Rate: Within the statistical window, if there are two or more commands that conflict with each other in execution within the same vehicle and the same time range, such as simultaneously requiring acceleration and deceleration, simultaneously requiring extended observation and immediate execution of strong actions, or having incompatible action combinations on the same segment, it is counted as a conflict command. The conflict command rate can be calculated as "number of conflict commands / total number of commands". Evidence Version Drift: For the same segment identifier, if the evidence version number is updated too frequently within the statistical window, or if the segment boundary is repeatedly re-estimated, or the alarm attribution frequently drifts, it can be counted as evidence version drift enhancement. This indicator can be quantified using "number of evidence version changes per unit time" or "percentage of times triggering re-estimated / attribution changes". Execution receipt mismatch rate: In the statistics window, if there is an instruction sequence number that is visible in the cloud but the terminal does not send back the corresponding execution evidence summary, or the sent execution evidence summary is inconsistent with the evidence version number recorded in the cloud, or the stage identifier is abnormal, such as only receiving the submission state receipt but not the preparatory state link record, then it is counted as a receipt mismatch; the mismatch rate can be counted as "number of mismatches / total number of instructions".

[0101] When the set of backend error indicators meets the preset degradation conditions, the cloud platform initiates adaptive parameter adjustment and issues updated terminal execution strategies, forming an evaluation feedback adjustment closed loop to suppress backend errors. To ensure feasibility, degradation conditions can be triggered by multiple indicators simultaneously to avoid mis-adjustment of parameters due to fluctuations in a single indicator. For example: if the duplicate distribution rate is consistently higher than the threshold, and the number of gating flips exceeds the upper limit within the statistical window, it is determined as "distribution link jitter-type degradation"; if the revocation bounce rate is consistently higher than the threshold, and the conflict command rate increases, it is determined as "rollback link instability-type degradation"; if the evidence version drift increases, and the execution receipt mismatch rate increases, it is determined as "evidence inconsistency-type degradation".

[0102] For different degradation types, the cloud platform can adjust control parameters and implement adjustment actions as follows: Adjusting the release and rejection thresholds: When frequent gating flips or repeated issuances occur in the backend, the cloud platform can appropriately raise or lower the release threshold to narrow or shift the gray zone range, thereby reducing the probability of strong actions entering the submission state and increasing the proportion of observation in the preparatory state. Adjusting the hysteresis threshold range: When the gating conclusion flips frequently in adjacent periods, the cloud platform can expand the hysteresis range so that the risk score does not trigger gating conclusion switching under small fluctuations, thereby reducing policy jitter. Adjusting the freeze window duration: When the gray zone stays for too long or the number of flips reaches the upper limit, the cloud platform can extend the freeze window duration, allowing only low-disturbance actions in the preparatory state within the freeze window, avoiding frequent triggering of strong actions that could cause greater disturbances. Adjusting the cancellation window duration: When the cancellation bounce rate is too high, the cloud platform can shorten the cancellation window or tighten the cancellation conditions to reduce bounce behavior such as "cancellation immediately after issuance, and issuance again after cancellation." Conversely, when evidence drift is strong but a certain level of control must be maintained, the cancellation window can be appropriately extended to enhance the observation time. Adjusting the cooldown period constraint: When strong actions cause significant back-disturbance and lead to increased short-term deviation fluctuations, the cloud platform can extend the cooldown period to prevent similar strong actions from re-entering the submission state within a certain period, avoiding frequent short-term interventions. Adjusting the level of strong actions: When background error indicators show that strong actions triggering leads to an increased conflict command rate or an increased receipt mismatch rate, the cloud platform can downgrade the level of strong actions from high / medium to low, or change some strong actions to low-disturbance actions that are only executed in the preparatory state, to reduce execution disturbances and receipt link pressure.

[0103] The cloud platform generates parameter change records during parameter adjustment and writes them into the corresponding evidence package to support review and calibration. The parameter change record includes at least: the indicator that triggered the degradation condition and its numerical range, the trigger time range, the name of the adjusted parameter, the values ​​before and after adjustment, the applicable scope (e.g., line / vehicle / semantic type / action type), and a summary of the adjustment reason. By associating and storing the parameter change record with the segment identifier, evidence version number, and instruction sequence number, it is possible to provide a traceable explanation for why duplicate issuance occurred, why reversal and bounce occurred, and why gating flipped, and to provide data support for long-term calibration of threshold and window parameters.

[0104] Embodiment 5 of the present invention: In order to adapt to link-limited scenarios such as weak coverage, congestion and latency fluctuations in cellular networks, and to reduce background scheduling errors caused by missing evidence or disordered arrival times, this embodiment adds an evidence protection strategy of hierarchical reporting of terminal-reported content based on Embodiments 1, 2, 3 or 4 of the present invention.

[0105] When segmenting the operation status into segments according to the semantics of bus operation events and generating versioned evidence, and reporting the segment summary to the cloud platform, the terminal divides the reported content into a summary layer and an extension layer: the summary layer includes at least the segment identifier, segment boundary, evidence version number and segment operation summary, and is set as the highest priority for reporting, so as to ensure that the cloud platform can still obtain the minimum evidence set for gating and conflict arbitration when the link is limited.

[0106] The extended layer includes original sample fragments, alarm details, or diagnostic details. These are retransmitted in batches when bandwidth is sufficient, or when the cloud platform detects evidence gaps based on the evidence version number, the cloud platform specifically requests the terminal to retransmit the extended layer data corresponding to the evidence version number. After receiving the summary layer evidence, the cloud platform can complete evidence consistency determination and action gating. If the extended layer coverage is insufficient or multiple versions of the same fragment arrive concurrently, the cloud platform enters an observation or freeze strategy, allowing only low-disturbance actions in the preparatory state, thereby suppressing repeated strong actions and backend logic errors caused by incomplete / inconsistent evidence arrival.

[0107] Embodiment Six of the Invention: Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of a public transport intelligent scheduling optimization system based on a multi-source data fusion model, provided by an embodiment of the present invention. The system includes: a data acquisition module, a segmentation and evidence generation module, a summary reporting module, an instruction receiving, parsing and registration module, and a two-stage execution and feedback module.

[0108] The system comprises several modules: a data acquisition module for collecting continuous sampling data and proactive safety alarm event data, generating a local data stream for the terminal; a segmentation and evidence generation module for segmenting operational status segments according to the semantics of bus operation events and generating versioned evidence; a summary reporting module for reporting segment summaries to the cloud platform; and an instruction receiving, parsing, and registration module for receiving dispatch instructions from the cloud platform and parsing and registering them. The dispatch instructions are generated by the cloud platform based on information reported by the terminal and include: an evidence version consistency determination identifier, an observation / freeze control identifier, a candidate dispatch action set identifier or action parameter set, intensity level and effective window parameters, a two-stage instruction, an instruction sequence number, and a field bound to the evidence version number. The two-stage instruction includes a preparatory state instruction and a submission state instruction. The preparatory state instruction corresponds to low-disturbance actions and carries a cancellation window parameter, while the submission state instruction corresponds to strong actions and carries submission condition parameters. The two-stage execution and feedback module is used to receive scheduling instructions and perform data processing based on the instruction sequence number and evidence version number. It is executed according to a two-stage mechanism of preparation state and submission state. In the preparation state, the execution state summary is continuously fed back within the cancellation window. In the submission state, after the strong action reaches the irreversible threshold, cancellation is prohibited and only compensation actions are allowed.

[0109] Embodiment 7 of the present invention: Figure 3 As shown, Figure 3 This invention provides a method for intelligent bus scheduling optimization based on a multi-source data fusion model, and its flowchart is used in a cloud platform. The specific steps are as follows:

[0110] A1: The cloud platform receives the segment summary reported by the terminal; wherein, the segment summary is obtained by the terminal based on the semantic segmentation of the bus operation event and generating versioned evidence, and the segment summary includes at least the segment identifier, segment boundary information, evidence version number and segment operation summary.

[0111] A2: The cloud platform performs scheduling generation processing based on fragment summaries and forms candidate scheduling actions; the processing includes at least: performing evidence version consistency determination and generating evidence version consistency determination identifier; when the determination is inconsistent, generating observation / freeze control identifier to trigger observation or freeze; when the determination is consistent, generating candidate scheduling action set identifier or action parameter set, and configuring intensity level parameters and effective window parameters for candidate scheduling actions.

[0112] A3: The cloud platform generates and issues scheduling instructions; the scheduling instructions include at least the evidence version consistency judgment identifier, the observation / freeze control identifier, the candidate scheduling action set identifier or the action parameter set, the intensity level and the effective window parameter, the two-stage instruction, the instruction sequence number, and the field bound to the evidence version number; the two-stage instruction is used to indicate the preparatory state instruction and the submission state instruction; the preparatory state instruction corresponds to a low-disturbance action and carries the cancellation window parameter, and the submission state instruction corresponds to a strong action and carries the submission condition parameter.

[0113] A4: The cloud platform uses a two-phase mechanism for submission determination and status updates. After issuing the preparatory state command, the cloud platform receives the execution state summary and the updated fragment execution summary corresponding to the current fragment identifier from the terminal within the cancellation window, and determines the submission conditions based on the updated evidence version number and evidence version consistency determination identifier. When the submission conditions are met, the cloud platform issues a submission state command bound to the same evidence version number. When the submission conditions are not met or the observation / freeze control identifier is triggered, the cloud platform prohibits the issuance of submission state commands and maintains the preparatory state low-disturbance action or generates cancellation / degradation control information.

[0114] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A public transport intelligent scheduling optimization method based on a multi-source data fusion model, used in a terminal, characterized in that, The method includes the following steps: S1: Collects continuous sampling data and proactive security alarm event data to generate local data streams on the terminal; S2: Segment the operation status into segments according to the semantics of bus operation events and generate versioned evidence, and report the segment summary to the cloud platform; The versioned evidence includes at least an evidence version number and a versioned evidence payload; The evidence version number is generated by at least a combination of fragment identifier, fragment boundary summary, summary caliber identifier and generation time sequence identifier; The versioned evidence payload includes at least a fragment execution summary and an event mapping summary corresponding to the fragment execution summary; The evidence version number is generated and reported in conjunction with the new versioned evidence payload when any of the following conditions are met: the fragment boundary is re-evaluated by delayed data or anomaly correction, the alarm attribution index is updated, the statistical dimension, sampling period or binning rule is updated, or the summary is changed from a missing marker to a valid marker. The type of versioned evidence includes at least one or more of the following: boundary version, attribution version, caliber version, or integrity version; The boundary version is used to characterize the re-estimation status of the start and end positions of the same segment, the attribution version is used to characterize the attribution change after the alarm event is aligned to the sampling index, the caliber version is used to characterize the change in the caliber of the statistical summary calculation, and the integrity version is used to characterize the change in evidence coverage caused by late retransmission. The fragment summary includes at least the fragment identifier, fragment boundary information, evidence version number, and fragment execution summary; S3: Receives scheduling instructions issued by the cloud platform and parses and registers them; The scheduling instruction is generated by the cloud platform based on the information reported by the terminal, and the scheduling instruction includes: evidence version consistency judgment identifier, observation / freeze control identifier, candidate scheduling action set identifier or action parameter set, intensity level and effective window parameter, two-stage instruction, instruction sequence number and field bound to evidence version number; The two-stage instructions include a preparatory state instruction and a commit state instruction. The preparatory state instruction corresponds to a low-disturbance action and carries a cancellation window parameter, while the commit state instruction corresponds to a strong action and carries a commit condition parameter. S4: After receiving the scheduling instruction, perform data processing based on the instruction sequence number and evidence version number, and execute according to the two-stage mechanism of preparatory state and submission state. In the preparatory state, the execution state summary is continuously transmitted back within the cancellation window. In the submission state, after the strong action reaches the irreversible threshold, cancellation is prohibited and only compensation actions are allowed.

2. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 1, characterized in that: The operational status segment is segmented according to the semantics of the bus operation event; The semantics of bus operation events include at least station-related semantics and non-station semantics; The site-related semantics include at least one or more of the following: inbound semantics, stop semantics, and outbound semantics; The non-station semantics include at least one or more of the following: cruise semantics, interval operation semantics, close following semantics, or lane change / lane change semantics.

3. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 1, characterized in that: The scheduling instruction also includes the purification results and stability assessment results obtained by the cloud platform from performing evidence purification and stability assessment on the consistent evidence when the evidence version consistency is determined to be consistent. The evidence purification includes at least performing availability discrimination and aggregation measurement on active safety alarm evidence to generate alarm availability and alarm cluster density, and performing persistence determination or multi-vehicle consistency determination on operational deviation evidence to generate abnormal confidence. The stability assessment includes at least determining the fluctuation range of segment boundary drift, alarm attribution drift, or summary statistics, and using the stability assessment results to adjust the intensity level or effective window of candidate scheduling actions, or to trigger a downgrade to a low-disturbance action.

4. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 1, characterized in that: The scheduling instruction receives the risk score and gating conclusion corresponding to the candidate scheduling action. The gating conclusions include approval, rejection, and gray zone. The gray zone is the gating state corresponding to the risk score being in the middle risk range between the approval threshold and the rejection threshold. When the gating conclusion is in the gray zone, only the preparatory action is performed and the reporting cycle / reporting duration of the evidence window is extended to trigger the data update required for subsequent rolling re-determination.

5. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 4, characterized in that: The risk score is calculated by the cloud platform based on the risk assessment feature vector that corresponds one-to-one with the candidate scheduling action when conducting a pre-action risk assessment of the candidate scheduling action. The risk assessment feature vector includes at least one or more of the following: longitudinal response statistical features and alarm event statistical features obtained from fragment execution summaries, evidence stability features obtained from evidence version consistency determination, and action intensity profile features obtained from candidate scheduling actions, their intensity levels, and effective windows. The evidence stability features are constructed from the evidence version consistency determination results and / or the stability assessment results of consistent evidence, including at least one or more of the following: fragment boundary re-estimation marker, alarm attribution drift, evidence version drift, or reaching out-of-order intensity. The motion intensity profile features include at least one or more of the following: strong motion disturbance sensitivity, anti-disturbance prediction bias index, or disturbance cost indicator. The anti-disturbance prediction deviation index is used to characterize the degree of reverse disturbance of the candidate strong action on the arrival prediction deviation, interval running time deviation, or train interval deviation.

6. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 4, characterized in that: The gating conclusion is obtained by the cloud platform based on risk scoring and combined with the release threshold and rejection threshold to form a gray zone; When the risk score falls into the gray zone and the gating conclusion is gray, only the corresponding candidate scheduling action is allowed to enter the preparatory state, and the evidence window is extended according to the rolling re-determination trigger parameter in the instruction to perform rolling re-determination data feedback. The rolling re-determination includes at least: continuously transmitting the execution state summary and the updated fragment execution summary within the extended evidence window, so that the cloud platform can update the risk score based on the updated evidence version consistency determination result, and send the updated risk score and gating conclusion to the terminal through subsequent scheduling instructions; When the updated risk score carried by the subsequent scheduling instruction received by the terminal meets the release condition in at least K consecutive rolling re-determinations and the consistency of the evidence version meets the stability condition, it is allowed to enter the submission state and execute the strong action of the submission state. When the updated risk score carried by the subsequent scheduling instruction received by the terminal meets the rejection condition or the consistency of the evidence version becomes unstable, the candidate scheduling action is rejected or downgraded to a low-disturbance action for execution. When the scheduling instruction received by the terminal carries a freeze window trigger flag indicating that the number of times the gating conclusion is flipped in an adjacent decision cycle reaches a preset limit or the gray zone stay time exceeds a preset limit, the terminal enters the freeze window and prohibits the execution of strong actions in the submission state within the freeze window, and only low-disturbance actions in the preparatory state are allowed. The received scheduling instructions also carry a gating reason summary, which is generated by the cloud platform when rejecting, downgrading or triggering a freeze window and associated with the corresponding evidence version number.

7. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 1, characterized in that: Step S4 also includes: sending back the execution evidence summary, wherein the sent back execution evidence summary is: associating the fragment summary, execution state summary and execution evidence summary with the corresponding fragment identifier, evidence version number and instruction sequence number and sending them back, so as to support the cloud platform to aggregate evidence packages according to fragment identifiers and calculate the set of background disorder indicators accordingly; The system receives the control parameter adjustment results issued by the cloud platform after triggering degradation conditions based on the set of background disorder indicators, and updates the terminal execution strategy according to the control parameter adjustment results, thereby forming an evaluation feedback adjustment closed loop to suppress background disorder.

8. The intelligent bus scheduling optimization method based on a multi-source data fusion model as described in claim 1, used in a cloud platform, characterized in that, Includes the following steps: A1: Segment summary reported by the receiving terminal; The segment summary is obtained by the terminal based on the semantic segmentation of the bus operation event and generating versioned evidence, and the segment summary includes at least the segment identifier, segment boundary information, evidence version number and segment operation summary; A2: Perform scheduling generation processing based on the fragment summary and form candidate scheduling actions; The process includes at least: performing an evidence version consistency determination and generating an evidence version consistency determination identifier; When an inconsistency is detected, an observation / freeze control flag is generated to trigger observation or freeze. When the results are consistent, a candidate scheduling action set identifier or action parameter set is generated, and intensity level parameters and effective window parameters are configured for the candidate scheduling action. A3: Generate and issue scheduling instructions; The scheduling instruction includes at least an evidence version consistency determination identifier, an observation / freeze control identifier, a candidate scheduling action set identifier or action parameter set, intensity level and effective window parameters, a two-stage instruction, an instruction sequence number, and a field bound to the evidence version number. The two-stage instructions are used to indicate the preparatory state instructions and the commit state instructions; the preparatory state instructions correspond to low-disturbance actions and carry undo window parameters, while the commit state instructions correspond to strong actions and carry commit condition parameters. A4: Submission determination and status update are based on a two-phase mechanism; Among them, after issuing the preparatory state instruction, the execution state summary and the updated fragment running summary corresponding to the current fragment identifier are received from the terminal in the cancellation window, and the submission conditions are determined based on the updated evidence version number and evidence version consistency judgment identifier. When the submission conditions are met, a submission status command bound to the same evidence version number is issued; When the submission conditions are not met or the observation / freeze control flag is triggered, the issuance of submission state commands is prohibited, and the preparatory state low-disturbance actions are maintained or the undo / degrade control information is generated.

9. A public transport intelligent dispatching and optimization system based on a multi-source data fusion model, used in a terminal, the system comprising: Data acquisition module, fragment segmentation and evidence generation module, summary reporting module, instruction receiving and parsing registration module, two-stage execution and feedback module; The data acquisition module is used to collect continuously sampled data and proactive security alarm event data to generate a local data stream for the terminal. The segmentation and evidence generation module is used to segment operation status segments according to the semantics of bus operation events and generate versioned evidence. The summary reporting module is used to report fragment summaries to the cloud platform; The versioned evidence includes at least an evidence version number and a versioned evidence payload; The evidence version number is generated by at least a combination of fragment identifier, fragment boundary summary, summary caliber identifier and generation time sequence identifier; The versioned evidence payload includes at least a fragment execution summary and an event mapping summary corresponding to the fragment execution summary; The evidence version number is generated and reported in conjunction with the new versioned evidence payload when any of the following conditions are met: the fragment boundary is re-evaluated by delayed data or anomaly correction, the alarm attribution index is updated, the statistical dimension, sampling period or binning rule is updated, or the summary is changed from a missing marker to a valid marker. The type of versioned evidence includes at least one or more of the following: boundary version, attribution version, caliber version, or integrity version; The boundary version is used to characterize the re-estimation status of the start and end positions of the same segment, the attribution version is used to characterize the attribution change after the alarm event is aligned to the sampling index, the caliber version is used to characterize the change in the caliber of the statistical summary calculation, and the integrity version is used to characterize the change in evidence coverage caused by late retransmission. The instruction receiving, parsing and registration module is used to receive scheduling instructions issued by the cloud platform and parse and register them. The scheduling instruction is generated by the cloud platform based on the information reported by the terminal, and the scheduling instruction includes: evidence version consistency judgment identifier, observation / freeze control identifier, candidate scheduling action set identifier or action parameter set, intensity level and effective window parameter, two-stage instruction, instruction sequence number and field bound to evidence version number; The two-stage instructions include a preparatory state instruction and a commit state instruction. The preparatory state instruction corresponds to a low-disturbance action and carries a cancellation window parameter, while the commit state instruction corresponds to a strong action and carries a commit condition parameter. The two-stage execution and feedback module is used to receive scheduling instructions and then perform data processing based on the instruction sequence number and evidence version number. It is executed according to a two-stage mechanism of preparatory state and submission state. In the preparatory state, the execution state summary is continuously fed back within the cancellation window. In the submission state, after the strong action reaches the irreversible threshold, cancellation is prohibited and only compensation actions are allowed.

Images