A customized bus travel method and device based on an intelligent bus stop

CN122906889APending Publication Date: 2026-10-13WUHAN XIAOMA LIANCHENG TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611054145.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-15
Publication Date
2026-10-13

AI Technical Summary

Technical Problem

[0003]然而,乘客购票信息与司机端之间缺乏实时同步机制,特别是已购票的新乘客无法准确找到站点,司机在接乘客时需长时间等待或耗时寻找乘客,严重影响运营准点率与出行体验

Benefits of technology

[0017]本发明实施例提供的上述技术方案的有益效果至少包括:

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122906889A_ABST
    Figure CN122906889A_ABST
Patent Text Reader

Abstract

The application discloses a customized bus travel method and device based on intelligent bus stop. The method comprises the following steps: obtaining the travel demand of passengers, matching the intelligent bus stop position information according to the travel demand, generating the waiting information based on the travel information and the intelligent bus stop position information, synchronizing the waiting information to the vehicle terminal of the corresponding customized bus, generating the estimated arrival time of the customized bus according to the waiting information by the vehicle terminal, the waiting information comprising the intelligent bus stop position, the number of passengers and the travel time demand, and providing the intelligent bus stop position information and the estimated arrival time fed back by the vehicle terminal to the passengers. The application matches the position information of the intelligent bus stop, so that the bus stop becomes the information hub between the passengers and the drivers, the waiting information is synchronized to the vehicle terminal, the drivers can know the accurate waiting position and the number of people in advance, the bus stop position and the estimated arrival time are fed back to the passengers, the two-way guidance that the passengers can find the bus stop and the drivers can find the passengers is realized, and the operation punctuality rate of the customized bus and the travel experience of the passengers are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a customized public transportation method and device based on intelligent bus stop signs. Background Technology

[0002] Customized buses, as an important supplement to the urban public transportation system, can flexibly plan routes and stops according to passengers' actual travel needs. They effectively solve the contradiction between insufficient coverage of regular buses and personalized travel needs, and play an increasingly important role in scenarios such as commuter connections, medical lines, campus lines, or temporary lines during tourist seasons. They have significant value in improving the utilization efficiency of public transportation resources, alleviating urban congestion, and meeting diverse travel needs.

[0003] However, there is a lack of real-time synchronization mechanism between passenger ticketing information and driver information. In particular, new passengers who have already purchased tickets cannot accurately find the station. Drivers have to wait for a long time or spend a lot of time searching for passengers, which seriously affects the punctuality rate and travel experience. Summary of the Invention

[0004] To improve the efficiency of public transportation resource utilization and the on-time performance, this invention provides a customized bus travel method and device based on smart bus stop signs. By acquiring passenger travel needs and matching them with the location information of smart bus stop signs, the bus stop signs become the information hub between passengers and drivers. Based on travel needs and bus stop location, waiting information is generated and synchronized to the on-board terminal, allowing drivers to know the precise waiting location and number of passengers in advance. At the same time, the location of the bus stop signs and the estimated arrival time are fed back to passengers, realizing two-way guidance that allows passengers to find the bus stop and drivers to find passengers. This effectively solves the technical problems of difficulty in locating temporary waiting points for customized buses and drivers blindly picking up passengers, thereby improving the on-time performance of customized buses and the passenger travel experience.

[0005] As one aspect of the present invention, embodiments of the present invention provide a customized public transportation method based on intelligent bus stop signs, comprising:

[0006] Obtain passengers' travel needs and match smart bus stop location information based on those needs;

[0007] Based on the travel information and the location information of the smart bus stop, waiting information is generated and synchronized to the on-board terminal of the corresponding customized bus. The on-board terminal generates the estimated arrival time of the customized bus based on the waiting information. The waiting information includes at least the location of the smart bus stop, the number of passengers, and the travel time requirement.

[0008] The location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal are provided to the passenger.

[0009] As another aspect of the present invention, embodiments of the present invention provide a customized public transportation device based on a smart bus stop sign, comprising:

[0010] The data parsing module is used to obtain passengers' travel needs and match the location information of smart bus stops based on these travel needs.

[0011] The information synchronization module is used to generate waiting information based on the travel information and the location information of the smart bus stop and synchronize it to the on-board terminal of the corresponding customized bus. The on-board terminal generates the estimated arrival time of the customized bus based on the waiting information. The waiting information includes at least the location of the smart bus stop, the number of passengers, and the travel time requirement.

[0012] The information feedback module is used to provide the passenger with the location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal.

[0013] As another aspect of the present invention, embodiments of the present invention provide an intelligent bus stop sign, the intelligent bus stop sign comprising at least: a display module, a communication module, a control module, a positioning module, and a mobility module, wherein:

[0014] The control module is connected to the display module, the communication module, the positioning module, and the motion module, respectively.

[0015] The mobile module includes a main support and a mobile base. The main support is a vertical shell structure of the smart bus stop sign, used to support and fix the hardware equipment. The mobile base is installed at the bottom of the main support.

[0016] The control module includes a memory and a processor. The memory stores a computer program, and the processor executes the customized public transportation method based on smart bus stop signs.

[0017] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following:

[0018] This invention provides a customized bus travel method based on smart bus stop signs. The smart bus stop sign serves as a physical information hub between passengers and drivers. By acquiring passengers' travel needs and matching them with location information, the bus stop sign becomes a unified and prominent identifier for temporary waiting points for customized buses. This solves the core problem of passengers finding it difficult to locate waiting points due to the temporary nature and lack of fixed signage at bus stops. Drivers can learn about the waiting passengers at the stop in advance and directly and accurately pick them up upon arrival, avoiding operational delays caused by blindly waiting or searching for passengers. The location of the bus stop sign and the estimated arrival time fed back from the onboard terminal are provided to passengers, allowing them to clearly know their waiting location and rationally plan their waiting time. This invention improves the passenger pick-up efficiency and route punctuality of customized buses and optimizes the driver-passenger collaboration mechanism.

[0019] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0020] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0021] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0022] Figure 1 This is a flowchart of a customized public transportation method based on smart bus stop signs provided in an embodiment of the present invention;

[0023] Figure 2 This is a structural diagram of a customized public transportation system based on smart bus stop signs provided in an embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of the structure of the customized public transportation device based on smart bus stop signs provided in an embodiment of the present invention. Detailed Implementation

[0025] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0026] In customized bus operation scenarios, drivers cannot know the number of passengers waiting at each stop in advance while the vehicle is in motion, and passengers may leave before boarding. While some customized bus systems can accurately indicate the number of passengers at each stop, the temporary and random nature of customized buses (many stops are not fixed) means that new passengers who have purchased tickets cannot accurately locate their stops. Drivers then need to wait for extended periods or spend considerable time searching for passengers, easily causing operational delays and reducing route punctuality. Furthermore, passengers may experience a negative travel experience due to drivers not stopping or waiting for extended periods. These problems are particularly prominent in customized bus operation scenarios such as dynamic response buses and on-demand buses.

[0027] In view of the above problems, the inventors realized that the core reason for the poor operation of existing customized buses is the lack of a real-time synchronization mechanism between passengers and drivers. Passengers cannot find the station on time and accurately, drivers cannot accurately understand the waiting situation of passengers, and cannot flexibly arrange the route (if they can know in advance that there are no passengers at some stations, they can ignore the station and go directly to the next station).

[0028] To address this, this invention proposes a customized public transportation method based on intelligent bus stop signs. The intelligent bus stop sign serves as a physical waiting guidance terminal, enabling passengers to quickly locate their waiting points based on prominent signage. The intelligent bus stop sign acquires passenger travel needs and matches them with bus stop location information, generating waiting information including sign location, passenger numbers, and travel time requirements. This information is then synchronized to the onboard terminal, allowing the driver to be aware of the waiting status at each temporary waiting point in advance and skip that stop if there are no passengers. Simultaneously, the bus stop location and estimated arrival time are fed back to passengers, enabling them to accurately locate temporary waiting points and rationally plan their waiting time based on prominent signage. This invention uses the intelligent bus stop sign as a physical information hub, achieving the dual goals of accurate passenger waiting point location and efficient passenger pick-up for drivers.

[0029] It should be noted that the implementing entity of each embodiment of this application can be a computing service system with data processing, network communication, and program execution functions, such as an electronic system capable of realizing the above functions, or a customized bus travel system based on smart bus stop signs, etc. The following description uses a customized bus travel system based on smart bus stop signs (hereinafter referred to as "the System") as an example to illustrate the following embodiments.

[0030] Example 1

[0031] Reference Figure 1 As shown, this embodiment of the invention provides a customized public transportation method based on smart bus stop signs, including steps S10 to S30:

[0032] Step S10: Obtain the passenger's travel needs and match the location information of the smart bus stop according to the travel needs.

[0033] The customized public transport method based on smart bus stop signs provided in this application can be applied to customized public transport systems based on smart bus stop signs. For example... Figure 2 As shown in the structure diagram, the system is divided into two parts: a hardware system and a software system. The two communicate bidirectionally and work together. At the same time, the hardware system establishes a real-time connection with the external customized bus dispatch management platform and bus terminal through the communication module, forming a complete operation system.

[0034] In its implementation, the hardware system includes a core control module, an AI (Artificial Intelligence) interaction module, a ticketing and verification module, a communication module, a power supply module, and a status indicator module. The core control module uses an embedded quad-core processor with a 2.0GHz clock speed, responsible for data processing, logic control, and command issuance for the entire system. The AI ​​interaction module consists of a high-definition touchscreen display, a microphone array, and high-fidelity speakers, supporting both voice dialogue and touchscreen input. Voice recognition utilizes natural language processing technology, achieving a Mandarin recognition accuracy of over 95% and supporting common dialects, with a response time of less than 3 seconds. The ticketing and verification module includes a QR code generation module and a scanning and recognition unit, capable of generating a unique QR code for passengers in real time based on their ticket purchase information, and supporting QR code payments from mainstream payment platforms.

[0035] The software system is embedded in the core control module, which includes an AI intelligent dialogue engine and a real-time information synchronization system. The AI ​​intelligent dialogue engine, based on natural language processing algorithms, has functions such as passenger intent recognition, destination parsing, and question answering. It can accurately identify passenger travel needs and retrieve matching customized bus routes, and also has a memory function to record frequently used routes. The real-time information synchronization system uses 5G high-speed communication technology to establish a three-way real-time information synchronization link between bus stop signs, the dispatch management platform, and the onboard terminal, with a synchronization latency of less than 1 second.

[0036] The hardware system establishes real-time data communication with the customized bus dispatch management platform and bus-mounted terminals through a communication module (4G / 5G and Wi-Fi dual-mode), enabling two-way synchronization of ticketing information, vehicle information, waiting information, and passenger flow data to ensure consistency among the three parties. The overall system structure adopts a modular design, with each module operating independently and being flexibly disassembled and maintained. The main base is movable, allowing for adjustments to station locations based on passenger flow demands.

[0037] Based on the collaborative operation of the above modules, this invention achieves a closed-loop process from passenger demand acquisition to information synchronization. The following provides a detailed description of steps S10 to S30.

[0038] It should be noted that the travel demand in step S10 refers to the travel intention expressed by the passenger, such as spoken or touch-selected information like "I want to go to Train Station A" or "to the City Hospital." Passengers interact with the smart bus stop sign through voice input or touch screen input. The destination information, i.e., the specific location name or point of interest that the passenger wishes to reach, is accurately extracted from these original expressions. For example, when a passenger says "I want to go to Square B," the named entity recognition technology in natural language processing, combined with the geographic information database, standardizes the location mapping and resolves "Square B" as the destination.

[0039] Furthermore, based on the aforementioned destination information and the geographical coordinates of the current smart bus stop sign itself, the current location of the bus stop sign is matched as the passenger's recommended waiting point, that is, informing the passenger that "the location of your current smart bus stop sign is the boarding point," enabling the passenger to quickly locate the waiting point based on the prominent physical sign of the bus stop sign, avoiding the inability to find the boarding point due to the lack of unified signage for temporary waiting points.

[0040] Step S101: Obtain the real-time geographic coordinates and deployment scene identifier of the current bus stop sign. The deployment scene identifier is used to distinguish the service scenarios of different buses.

[0041] To improve the accuracy of destination resolution, the system first obtains the real-time geographic coordinates of the bus stop itself, such as latitude and longitude (e.g., 30°32′N, 114°18′E) through the built-in GPS module.

[0042] Simultaneously, it acquires deployment scenario identifiers, i.e., pre-configured tags, to distinguish the service scenario type of the bus stop. For example, an identifier of "commuter shuttle" indicates that the bus stop serves commuter routes during morning and evening rush hours; an identifier of "hospital shuttle" indicates that it serves medical scenarios; and an identifier of "campus shuttle" indicates that it serves the area around schools. Passenger travel patterns and frequently visited destinations differ significantly across scenarios. For example, in the hospital shuttle scenario, passengers more often go to major hospitals and pharmacies; in the campus shuttle scenario, passengers more often go to train stations and shopping districts. This identifier helps the system subsequently invoke targeted acoustic models and interaction strategies.

[0043] Step S102: Collect passengers' travel needs via voice input or touch input.

[0044] It should be understood that voice input is collected via a microphone array consisting of multiple microphones, capable of directionally picking up the voices of passengers within a range of 0.5 to 3 meters in front of the station sign, while suppressing environmental noise such as wind and vehicle horns. Touch input is achieved through a high-brightness, anti-glare touchscreen, allowing passengers to directly tap frequently used destination buttons on the screen, handwrite place names, or select from their history. Both input methods can coexist, allowing passengers to choose according to their preferences. For example, an elderly passenger unfamiliar with mobile phone operation might directly say "I want to go to the children's hospital" to the station sign, while a younger passenger might quickly tap the "Train Station A" shortcut button on the screen. The system collects these input signals in real time and performs preliminary digital encoding in preparation for subsequent fusion processing.

[0045] Step S103: Using the real-time geographic coordinates and the deployment scenario identifier as context constraints, perform dual-channel semantic feature fusion on the travel demand to generate a structured travel intent.

[0046] It should be noted that dual-channel refers to processing the semantic information of both the voice input channel and the touch input channel simultaneously. Semantic features are extracted from each channel: the voice channel converts audio into text using speech recognition technology and includes features such as phonemes and acoustic confidence; the touch channel directly acquires the selected location or handwritten text and includes interactive features such as touch trajectory and press duration.

[0047] By using real-time geographic coordinates and deployment scenario identifiers as contextual constraints, the features of the two channels are fused.

[0048] For example, the bus stop is located in front of a top-tier hospital (the scene is labeled "Hospital Shuttle"). A passenger says "Going to the outpatient department" and simultaneously taps the "Register" button on the screen. The system comprehensively judges: the geographical coordinates indicate that there are outpatient buildings of several hospitals nearby, and the scene label suggests that this stop mainly provides medical services. Therefore, "Hospital A Outpatient Department" is resolved as the specific destination. The system ultimately generates a structured travel intention {Destination: Hospital A Outpatient Department; Travel Mode: Customized Bus; Expected Time: As soon as possible; Confidence Level: 0.92}.

[0049] Step S104: Based on the spatial distance between the destination in the structured travel intention and the real-time geographic coordinates, obtain the final smart bus stop location information.

[0050] After obtaining the destination from the structured travel intent, the system calculates the spatial straight-line distance or road network distance between the destination and the current bus stop's geographic coordinates to determine if the current bus stop is suitable as a waiting point for the passenger. Based on the distance, the system makes the following judgments: If the distance is within a preset service radius (e.g., less than or equal to 5 kilometers), the real-time geographic coordinates of the bus stop are matched as the passenger's waiting point, informing the passenger that "your current smart bus stop location is the boarding point," allowing the passenger to quickly locate their waiting position based on the prominent physical signage. If the distance exceeds the preset service radius (e.g., greater than 5 kilometers), it indicates that the destination is outside the service range of this bus stop. In this case, a multi-route transfer pre-search is performed, searching the bus route database for customized bus route combinations originating from this bus stop and ending at the destination. If a transfer route exists, the bus stop is still matched as the passenger's waiting point, and a transfer plan is generated for the passenger's reference. If no transfer route exists, the passenger is notified that this bus stop cannot serve the destination, and the system recommends the nearest other smart bus stop location that can serve the destination. Finally, the system outputs the real-time geographic coordinates of the current smart bus stop sign as the waiting point location information.

[0051] In one implementation, step S103 includes steps S1031 to S1034:

[0052] Step S1031: Based on the deployment scene identifier, call the corresponding scene acoustic model to perform microphone array beamforming noise reduction and dialect phoneme correction on the travel demand of the voice input, and obtain standard speech features.

[0053] This step involves refined processing of the voice input channel. First, a pre-trained scene acoustic model is selected based on the deployment scene identifier. Different scenes have different environmental noise and dialect distributions; for example, a hospital scene might contain broadcasts and ambulance sounds, while a school scene might have school bells and student noise. The scene acoustic model is a neural network model trained on clean voice data, mixed with the scene-specific noise.

[0054] Furthermore, beamforming noise reduction is achieved using a microphone array: by adjusting the phase and amplitude of the signals from each microphone, the signal from the direction of passengers in front of the bus stop sign is enhanced, while noise from other directions is suppressed. For example, when a vehicle passes by the bus stop sign and generates 80 decibels of noise, but a passenger's voice is only 60 decibels, beamforming can enhance the passenger's voice to a comprehensible level.

[0055] Next, dialect phoneme correction is performed: the system has built-in phoneme mapping tables for common dialects such as Wuhan dialect and Chengdu dialect, and corrects the dialects to standard Mandarin to obtain standard speech features, that is, a vector containing parameters such as phoneme sequence, acoustic confidence, and speech rate.

[0056] Step S1032: Retrieve historical touch hotspot data based on the real-time geographic coordinates to predict the interaction path of the travel demand of the touch input and obtain standard touch features.

[0057] Based on the real-time geographic coordinates of the current bus stop sign, historical touch hotspot data stored for that sign is retrieved. Hotspots refer to areas on the touchscreen screen that passengers click on most frequently. For example, if a bus stop is near a large residential community and a farmers' market, historical data shows that passengers most often click the "Go Home" and "Go to the Market" buttons; the screen areas containing these buttons are considered hotspots.

[0058] Based on the coordinates of the passenger's current touch, combined with heatmap data, the system predicts the passenger's possible intentions. For example, if the passenger's finger approaches the bottom right corner of the screen, and historical heatmap data shows that 90% of clicks on the bottom right corner are for "Train Station A," the system predicts the passenger's intention is to go to Train Station A and preloads the corresponding route information. Simultaneously, the system extracts touch features, including click coordinates, pressure values, swipe trajectory (if it's a swipe operation), and dwell time, forming a standard touch feature vector. If a passenger quickly clicks the same location twice in succession, it may indicate an urgent need for travel, and the system will prioritize this request.

[0059] Step S1033: Based on the standard voice features and the standard touch features, incremental learning is performed on the deployment scenario identifier to generate the final structured travel intent.

[0060] This step achieves deep fusion and online learning of dual-channel features, concatenating standard speech features and standard touch features into a joint feature vector. For the current deployment scenario, a lightweight incremental learning model is invoked, such as a shallow neural network based on online stochastic gradient descent. This model comprehensively considers information from both channels: if the speech and touch features point to the same destination, a high-confidence structured travel intention is output; if they contradict each other (e.g., the speech says "go to the train station," but the touch input is "go to the bus station"), the system makes a decision based on historical statistics. For example, in a hospital scenario with many elderly passengers, speech is prone to errors due to dialects, while touch input is more reliable, so the touch intention is prioritized. Simultaneously, the model incrementally updates the parameters corresponding to the scenario identifier based on the interaction results, such as updating the weight ratio of speech confidence to touch confidence in that scenario, making subsequent parsing increasingly accurate. The final generated structured travel intention includes fields such as destination name, travel purpose category, and time urgency.

[0061] Step S1034: Based on the difference between the confidence levels of the standard voice features and the standard touch features, the user type is inferred in reverse to switch the corresponding interaction mode.

[0062] It should be noted that the confidence level of standard speech features comes from the posterior probability output by the speech recognition module. For example, the probability of recognizing "go to road A" is 0.7. The confidence level of standard touch features is based on the hot zone matching degree. For example, the probability of the click position falling in the center of the "road A" hot zone is 0.95. The difference between the two reflects the possible behavioral patterns of users.

[0063] If the voice confidence level is significantly lower than the touch confidence level (e.g., 0.4 vs 0.9), it is inferred that the passenger may be elderly or a non-Mandarin speaker, as their voice input is difficult to recognize but their touch operation is accurate. In this case, the system automatically switches to "Age-Friendly Interaction Mode": increasing screen font and button size, enabling slow voice broadcasting, and simplifying the subsequent ticketing process to the minimum number of clicks. Conversely, if the voice confidence level is high but the touch confidence level is low (e.g., 0.95 vs 0.5), it is inferred that the passenger may be visually impaired or accidentally touched the screen in a hurry, and the system switches to "Voice Priority Mode," where all confirmation operations are primarily completed via voice commands, reducing reliance on touch. If both confidence levels are low, a clarification dialogue is initiated, such as asking via voice, "Where do you want to go? Please repeat." This adaptive switching greatly improves the user-friendliness for different groups.

[0064] Step S20: Based on the travel information and the location information of the smart bus stop, waiting information is generated and synchronized to the on-board terminal of the corresponding customized bus. The on-board terminal generates the estimated arrival time of the customized bus according to the waiting information. The waiting information includes at least the location of the smart bus stop, the number of passengers, and the travel time requirement.

[0065] It should be understood that structured waiting information is generated based on passenger travel information (including the parsed destination, expected departure time, etc.) and the matched smart bus stop location information. This waiting information includes at least three core components: first, the location of the smart bus stop, i.e., the real-time geographic coordinates and text description of the current bus stop, used to inform the driver and passengers of the specific waiting location; second, the number of passengers, i.e., the actual number of people waiting to board at the bus stop; and third, the travel time requirement, i.e., the passenger's expected departure time or the latest acceptable waiting time.

[0066] Furthermore, the waiting information is synchronized in real time to the onboard terminal of the corresponding customized bus route via the communication module. After receiving the waiting information, the onboard terminal automatically calculates and generates the estimated arrival time of the bus stop based on the vehicle's current real-time location, speed, and road conditions ahead, providing the driver with accurate decision-making information. Through this information synchronization mechanism, drivers can know the waiting status of each temporary waiting point in advance and skip a stop if there is no need to wait there, avoiding unnecessary stops and waiting.

[0067] In one implementation, steps B201 to B203 are included before step S20:

[0068] After parsing the destination information, the system further searches the bus route database based on the destination information to generate the optimal ticketing plan. This step relies on the AI ​​intelligent dialogue engine and real-time information synchronization system in the software system, combined with the core control module and communication module in the hardware system, to achieve dynamic route matching and plan optimization.

[0069] The system searches the bus route database for feasible routes from the current bus stop to the destination, and generates an optimal ticketing plan by comprehensively considering factors such as the passenger's expected departure time and the number of people traveling with them. The bus route database is not static data but is generated in real-time based on passenger flow statistics at each stop, reflecting dynamic operational adjustments, such as adding express buses during peak hours or temporarily removing inefficient stops. The optimal ticketing plan includes key information such as route number, departure time, fare, estimated travel time, and number of available seats.

[0070] Step B201: Based on the destination information and the real-time geographic coordinates of the current bus stop, retrieve the bus route database with the real-time geographic coordinates as the starting point and the destination information as the ending point to obtain candidate routes. The bus route database is generated in real time based on passenger flow statistics for each stop.

[0071] The system obtains the final destination information and the real-time geographic coordinates of the bus stop itself. For example, the current bus stop is located at No. 1037, a certain road in a certain district of City A, and the destination is "International Airport A". Using these coordinates as the starting point and the destination as the ending point, the system performs a directed graph shortest path search in the bus route database to find all customized bus routes that can connect the starting point to the destination. Unlike regular buses, customized bus routes may include multiple optional routes, such as direct routes, routes requiring one transfer at a hub station, and slower routes with more stops.

[0072] The real-time nature of the bus route database is reflected in the fact that operators dynamically adjust the stops and departure frequencies of each route for the following day based on the passenger flow statistics of each stop from the previous day. For example, if no one buys a ticket at stop A along a certain route for three consecutive days, the system automatically removes it from the route database, so that the search results no longer include this inefficient stop. After obtaining candidate routes, each route is accompanied by dynamic attributes such as the number of remaining seats, estimated arrival time, and fare.

[0073] Step B202: Based on the passenger's desired departure time and number of companions, sort the candidate routes under multi-objective constraints to generate the optimal ticket purchase plan.

[0074] After obtaining a set of candidate routes, the system further filters and sorts them based on passengers' personalized needs. When using the station sign, passengers can not only state their destination but also add their desired departure time and number of companions via voice or touch. For example, a passenger can say, "I need to go to train station A, two people, preferably departing within half an hour." The system then extracts the desired departure time as "within half an hour" and the number of companions as 2.

[0075] Multi-objective constraint ranking refers to considering two or more optimization objectives simultaneously: minimizing waiting time and maximizing seat occupancy rate. For each candidate route, the system calculates the difference between its next departure time and the current time as the waiting time. Then, it compares the remaining seats on that route with the number of people traveling together to obtain the seat occupancy rate (if the number of remaining seats is greater than or equal to the number of people traveling together, the occupancy rate is 100%; otherwise, it uses the actual percentage). The waiting time and seat occupancy rate are then normalized and assigned different weight coefficients. For example, in time-sensitive scenarios, the waiting time has a weight of 0.7, and the seat occupancy rate has a weight of 0.3; conversely, during peak periods when seats are scarce, the weight of the seat occupancy rate is increased. Finally, each route receives a priority score, and the route with the highest score is the preliminary optimal solution.

[0076] Step B203: Bind the optimal ticketing scheme to the real-time geographic coordinates to generate a unique ticketing identifier code, and use the QR code generation process to allow the passenger to confirm the ticket purchase.

[0077] After determining the optimal ticketing plan, this plan is bound to the real-time geographic coordinates of the current bus stop, generating a globally unique ticketing identifier. This identifier is generated using a hash algorithm from fields such as timestamp, bus stop ID, route ID, and bus number, and is a 32-bit hexadecimal string. The purpose of this binding is to prevent passengers from purchasing tickets at bus stop A but boarding at bus stop B, as the different waiting areas at different bus stops would affect the driver's passenger pick-up schedule.

[0078] Furthermore, the system utilizes the QR code generation function in the ticketing and verification module to encode the ticket identification code into a QR code and display it on the touchscreen. Passengers can scan the QR code using mainstream payment applications such as WeChat or Alipay to access the payment page. After successful payment, the ticket identification code is marked as paid, triggering subsequent information synchronization steps. Simultaneously, the system can also automatically print a paper ticket using an optional thermal printer. The ticket also includes the QR code and flight information, making it convenient for elderly passengers to keep a copy.

[0079] As one implementation method, the core calculation process of multi-objective ranking in step B202 includes steps B2021 to B2024:

[0080] Step B2021: Determine the waiting time based on the passenger's expected departure time, determine the seat availability rate based on the number of passengers traveling with the passenger, and weight and fuse the waiting time and seat availability rate to generate a priority score.

[0081] It should be understood that the desired departure time can be a specific point in time, such as "before 14:30," or a relative time, such as "as soon as possible" or "within one hour." Based on the current time and the upper limit of the desired departure time, the maximum acceptable waiting time is calculated. For example, if the current time is 14:00 and the passenger says "departing within one hour," then the maximum waiting time is 60 minutes. For each candidate route, the actual waiting time is equal to the departure time of the next bus on that route minus the current time. If the actual waiting time is less than or equal to the maximum acceptable waiting time, the route is retained; otherwise, it is eliminated.

[0082] The seat availability rate is defined as follows: if the number of remaining seats R on a route is greater than or equal to the number of people traveling together P, the availability rate is 1.0; otherwise, it is R / P. For example, if there are 3 people traveling together and only 2 seats are left on a certain route, the seat availability rate is 0.67.

[0083] Waiting time is inversely normalized: shorter waiting times result in higher scores, calculated as: Waiting Time Score = 1 - (Actual Waiting Time / Maximum Acceptable Waiting Time). The waiting time score is then weighted and summed with the available seat availability rate, with the weights dynamically adjusted based on the scenario. For example, during morning rush hour, time sensitivity is high, so the weights are set to 0.8 for waiting time and 0.2 for available seats; while during off-peak hours, passengers are more concerned about seat availability, so the weights are set to 0.3 for waiting time and 0.7 for available seats. Each route ultimately receives a priority score between 0 and 1 for subsequent ranking.

[0084] Step B2022: If the number of people traveling together is greater than the number of seats available on a single route, then the number of people traveling together is split into multiple subgroups, and each subgroup is matched with the available seats of the same or adjacent trains to generate a collaborative ticketing plan.

[0085] When the number of passengers traveling together exceeds the number of remaining seats on a certain route, the traditional approach is to refuse to purchase tickets or to split the passengers onto different routes. This application provides a collaborative ticketing solution to avoid forcing passengers to split up. For example, a group of four people are traveling to the same destination, but a direct route only has three seats left. The system automatically splits the four people into two subgroups: one with three people and one with one person. On the same train, the three people occupy those three seats, while the remaining person tries to find another seat on the same train. However, if that train has no seats left, they are then matched with one remaining seat on an adjacent train (e.g., the next train in 20 minutes).

[0086] The system generates a collaborative ticketing plan: passengers can choose to have 3 people travel on the current trip and 1 person on the next trip, promising that the next trip will wait for that passenger (if the interval between the two trips is short, they can meet at an agreed stop). For passengers who do not wish to be separated, the system further searches whether there are other routes with more than 4 available seats, or recommends splitting them onto different routes but with similar destinations. In this plan, the system will prompt passengers with "It is suggested that you split into two groups and take consecutive trips on the same route, with an arrival time 20 minutes apart. Do you accept this?" and automatically calculate that the shared fare for each passenger remains unchanged.

[0087] Step SB023: If there are no direct routes with sufficient seats available during the desired departure time, then search for nearby stations within a preset radius, retrieve passenger data for ride-sharing, perform destination similarity matching and route merging feasibility calculation, and generate a merged route and fare sharing scheme.

[0088] It should be understood that when all direct routes within a passenger's desired departure time are unable to meet their demand (either no seats available or only a limited number of passengers can be accommodated), carpooling mode is activated. Using the current bus stop as the center, the system searches for other nearby stops within a preset radius, typically 500 to 1000 meters. The system retrieves travel demand data for passengers seeking carpooling at these nearby stops from the dispatch management platform, including each passenger's destination, desired departure time, and number of passengers traveling with them.

[0089] Furthermore, destination similarity matching is performed: the spatial distance between the destination of the passenger seeking a ride-sharing and the current passenger's destination is calculated; if the distance is less than 300 meters, it is considered "ride-sharing in the same direction." Simultaneously, route merging feasibility calculations are performed: it is determined whether the current passenger's origin and destination can be connected with the origin and destination of the passenger seeking a ride-sharing to form an efficient customized bus route, ensuring that the total mileage of the new route does not exceed 1.2 times the sum of the original two routes' mileages.

[0090] For example, a current passenger is traveling from station A to destination C, while a passenger waiting to share a ride at a nearby station B is traveling from station B to destination D, and C and D are only 200 meters apart. The system calculates that the merged route would be A→B→D→C, with an estimated increase in travel time of 8 minutes, which is feasible. Therefore, the merged route is generated, and the fare is recalculated: the total fare is distributed proportionally based on distance, or evenly. The system displays to the current passenger: "Two passengers at a nearby station are traveling to nearby destinations. They can be merged into a private car route, with an estimated increase in waiting time of 10 minutes. After the fare is shared, your fare will decrease from 15 yuan to 11 yuan. Do you agree to share the ride?"

[0091] Step SB024: Combine the route with the highest priority score, the collaborative ticketing scheme or the merged route, and the fare sharing scheme to form the optimal ticketing scheme.

[0092] Based on the results of the above calculations, the optimal ticketing plan is output. The system first determines whether there is a direct route with the highest priority score and sufficient remaining seats; if so, it is directly adopted as the optimal plan. If not, it checks whether there is a feasible collaborative ticketing plan (splitting the number of people traveling together into adjacent trains on the same route); if so, it recommends this plan. If no feasible collaborative plan is found, it attempts to generate a route merging and fare sharing plan.

[0093] The three options are sorted according to a preset priority order, and the highest priority and feasible one is displayed to the passenger as the final optimal ticketing option. For example, the system first prompts, "Recommended direct route, departing in 15 minutes, fare 10 yuan." If the passenger confirms, the process ends; if the passenger refuses due to insufficient seats, the system automatically switches to the collaborative ticketing option interface; if the passenger still does not accept, the carpooling option is displayed. All options clearly list the fare, departure time, seat availability, and transfer or waiting information. Passengers can confirm any option by tapping on the touchscreen, and the system will then enter the ticketing confirmation process.

[0094] In one implementation, step S20 includes steps S201 to S202:

[0095] Step S20 relies on the real-time information synchronization system in the software system and the communication module in the hardware system. Once a passenger completes payment by scanning a QR code with their mobile phone or by purchasing a ticket via card or cash, the system considers the passenger to have confirmed the optimal ticketing option. At this time, the waiting information generated from this ticket purchase is sent in real-time to the onboard terminal of the bus on the passenger's route for the driver to view. The waiting information includes at least: the location of the waiting point (i.e., the geographical coordinates of the current bus stop, which may include a text description such as "east side of No. 1037, a certain road"), the number of passengers, the destination (e.g., "Terminal 3 of International Airport A"), and the bus number (e.g., "Customized Bus G101, departing at 14:30").

[0096] Step S201: Based on the travel information and the location information of the smart bus stop, extract the waiting information corresponding to the unique ticket purchase identifier.

[0097] It should be noted that the system maintains a ticket purchase record table, with each record corresponding to a unique ticket purchase identifier. This identifier is generated after the passenger confirms their travel intention. Once the passenger confirms the purchase (payment successful), the system quickly retrieves the waiting information from the record table based on this ticket purchase identifier: the waiting point location is the real-time geographic coordinates and text location description pre-stored on the current smart bus stop sign. This location information will be synchronized to the onboard terminal to inform the driver of the specific stopping location; the number of passengers is either entered by the passenger or defaults to 1.

[0098] For example, the waiting information corresponding to a ticket purchase record is: waiting point location = "No. 789, a certain avenue, a certain bus stop", number of passengers = 2, destination = "Building C3, Science and Technology City, Area A", and bus number = "Customized Line L5, departing at 17:30". The system extracts this information from the database, encapsulates it into a structured data packet, and prepares to send it.

[0099] Step S202: The waiting information is synchronized to the on-board terminal of the corresponding customized bus through a dual-mode communication channel.

[0100] Dual-mode communication channel means that the communication module supports both 4G / 5G cellular networks and Wi-Fi wireless networks simultaneously, with each serving as a backup for the other, ensuring automatic switching to the other when the signal of one network is poor, thus improving reliability.

[0101] Based on the route number in the schedule information, the system retrieves the onboard terminal network address or device ID of the vehicle currently performing the task on that route from the dispatch management platform. For example, the current vehicle for the G101 customized bus is Hubei A·12345D, and its onboard terminal has already connected to the dispatch platform via 5G. The system sends the waiting information data packet encapsulated in step S301 to the designated port of the onboard terminal via the 5G network. Simultaneously, for redundancy and security, it will also be retransmitted once via Wi-Fi, with the onboard terminal automatically deduplicating the data.

[0102] Once synchronization is complete, the onboard terminal will send back a confirmation signal, and the status indicator light on the bus stop sign will flash once, indicating that the information has been delivered. The driver can see on the onboard terminal's display screen: "There are 2 passengers waiting at stop 1037 on the next route, destination A Airport. Please stop at this stop to pick them up." If passengers subsequently cancel their tickets, the system will also send a cancellation command and update the waiting information on the onboard terminal to prevent the driver from waiting unnecessarily.

[0103] It should be noted that, in practice, passengers use smart bus stop signs in ways that include, but are not limited to, the following two typical scenarios:

[0104] In the first scenario, passengers check and learn about customized bus routes in advance through mobile applications or online platforms, discovering that customized buses stop at a specific temporary waiting point. Passengers then follow the text descriptions or map locations on the application to reach the designated boarding point. Upon arrival, passengers are guided to the accurate waiting location by the prominent visual signage and status indicator lights on the smart bus stop sign, avoiding confusion due to the lack of standardized signage at temporary waiting points. Furthermore, passengers can confirm their ticket purchase through the smart bus stop sign or simply wait for the bus with their pre-purchased ticket on their mobile phone. For passengers who have already purchased tickets via mobile phone, the smart bus stop sign also displays the real-time location and estimated arrival time of the customized bus, providing peace of mind while waiting.

[0105] The second scenario: Passengers did not plan to take the customized bus in advance, but spontaneously decided to take it when passing by a smart bus stop along the roadside. For example, a passenger walks to a smart bus stop near a shopping area, sees the customized bus route information displayed on the sign, and realizes that they can take this route to their destination instead of taking a taxi or subway. The passenger simply says "I want to go to Train Station A" on the smart bus stop sign or selects the destination option via the touchscreen. The AI ​​interaction module of the smart bus stop sign collects the passenger's travel needs, analyzes the destination information, automatically retrieves matching customized bus routes, and generates the optimal ticketing plan. After confirmation, the passenger completes the ticket purchase by scanning a QR code to pay, and the bus stop sign synchronizes the waiting information to the corresponding route's onboard terminal. The passenger waits by the smart bus stop without needing to contact the driver or ask for the boarding location, as the driver has already received information about passengers waiting at the stop through the onboard terminal and will stop directly to pick them up. This method is particularly suitable for those with spontaneous travel needs, the elderly, or those unfamiliar with mobile phone operation.

[0106] By covering these two scenarios, smart bus stop signs serve two purposes: firstly, as physical guidance markers for passengers who have already purchased tickets, solving the problem of not being able to find their stop; and secondly, as self-service terminals for temporary ticket purchases, addressing the inconvenience of purchasing tickets via mobile phone. Drivers, on the other hand, can access the waiting information synchronized with the smart bus stop signs, allowing them to know the waiting status of each temporary waiting point in advance, without relying on mobile phones or passenger phone calls, thus achieving a standardized and visualized passenger pick-up process.

[0107] Step S30: Provide the passenger with the location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal.

[0108] The smart bus stop sign displays real-time geographic coordinates and textual descriptions of its location on its touchscreen screen, allowing passengers to confirm their current waiting area is the correct boarding point and avoid getting lost due to the lack of physical signage at temporary waiting areas. Simultaneously, the estimated arrival time calculated by the onboard terminal based on waiting information is fed back to the bus stop sign in real time and displayed to passengers, enabling them to plan their waiting time accordingly.

[0109] Furthermore, by collecting passenger flow data generated during the operation of each bus stop, and using this data as the basis for adjusting the location of the bus stops, intelligent scheduling of hardware resources can be achieved, allowing them to move in accordance with travel demand. This step relies on a mobile module, including a main support and a mobile base. The main support is the vertical shell structure of the bus stop, used to support and fix hardware equipment such as the touch screen display, core control module, communication module, and ticketing and verification module, ensuring stable operation of each module in outdoor environments. The mobile base is installed at the bottom of the main support, and its bottom is equipped with lockable casters. Under normal use, the casters are locked to ensure the stability of the bus stop. When the bus stop needs to be adjusted, maintenance personnel unlock the casters and push the bus stop to the new stop, then lock it again after it is in place, enabling flexible migration and rapid deployment of the bus stop, adapting to the dynamic adjustment needs of customized bus temporary waiting points.

[0110] Specifically, after each passenger completes a ticket purchase, the system includes that purchase record in the passenger flow statistics. The passenger flow data includes the number of ticket purchases, the destination distribution of passengers, and the distribution of ticket purchases at different times.

[0111] Passenger flow data at bus stops is stored in the local storage module of the bus stop sign and periodically reported to the customized bus dispatch management platform via the communication module. The platform then aggregates, cleans, and analyzes the passenger flow data from each stop. When the system detects that the passenger flow data at a certain stop meets the preset migration conditions, it triggers a migration command for the smart bus stop sign to remove it from an inefficient stop. When the system detects that there is high travel demand in a certain area but no bus stop sign is yet available, it triggers a deployment command for the smart bus stop sign to guide the operator to deploy new bus stops in areas with high demand.

[0112] Through the collaborative triggering mechanism of the aforementioned migration instructions and deployment instructions, the system realizes the dynamic optimization and configuration of bus stop resources within the region, enabling physical equipment to adapt to changes in passenger flow, avoiding resource idleness issues in the fixed installation mode, and improving the service coverage efficiency of customized buses.

[0113] In one implementation, step S30 is followed by steps A301 to A304:

[0114] Step A301: Collect station passenger flow data at the waiting point location. The station passenger flow data includes the number of ticket purchases and the distribution of passengers' destinations and time periods.

[0115] After information synchronization is completed, the ticket purchase record will be used for passenger flow statistics. Station passenger flow data refers to the summary information of all ticket purchases that occur at this station within a certain time range. This information is stored in the station's local storage module and periodically reported to the dispatch management platform.

[0116] Step A302: If the station passenger flow data meets the preset migration conditions, the smart bus stop sign is triggered to make a migration command. In response to the migration command, the bottom universal wheels of the bus stop sign are unlocked and it is pushed to the new station. The real-time geographic coordinates and deployment scene identifiers are updated to adapt to the service scene of the new station. The preset migration conditions are that the average daily passenger flow is lower than a threshold within a consecutive preset period.

[0117] It should be noted that the specific parameters for the preset migration conditions are: the average daily number of ticket purchases must be below a certain threshold (e.g., less than 5 people per day) within a consecutive preset period (e.g., 30 consecutive days). If a bus stop sign is used by fewer than 5 people per day on average for a whole month, it indicates that the passenger demand at that stop is very low. Continuing to keep the sign would be a waste of equipment resources (the hardware cost of each smart bus stop sign ranges from several thousand to tens of thousands of yuan) and would also occupy public space. In this case, the system generates a bus stop sign migration instruction, which can be displayed on the touch screen of the bus stop sign and simultaneously pushed to the operator's maintenance personnel. For example, the screen might display a message stating, "This stop has only had an average daily passenger flow of 2 people for 30 consecutive days. It is recommended to migrate to a nearby stop with higher demand." After confirmation by the maintenance personnel, the migration can be executed.

[0118] It should be understood that the main base of the AI ​​smart bus stop in this application is equipped with lockable casters. Under normal use, the casters' brakes are locked, and the bus stop is stable and does not move. Upon receiving a relocation instruction and with the arrival of maintenance personnel, the casters' brakes can be unlocked using a special tool or an electronic unlocking button. The maintenance personnel then push the bus stop to a pre-selected new location, such as moving it from the entrance of an old residential area with an average daily foot traffic of only 2 people to the entrance of a newly opened large shopping mall nearby.

[0119] Upon arrival at the new station, the omnidirectional wheel brakes are re-locked to ensure the station sign's stability. Then, maintenance personnel manually or automatically update the real-time geographic coordinates to the new station's latitude and longitude via the station sign's management interface. Simultaneously, based on the new station's service scenario (for example, the area around a shopping mall might primarily serve shopping and dining needs), the deployment scenario identifier is reset, for instance, changing from "old residential area" to "commercial district shuttle." The status indicator light on the station sign will flash green three times to indicate that the coordinate and scenario updates are complete, and the system will automatically restart relevant services to apply the new configuration.

[0120] Step A303: If the station passenger flow data meets the preset deployment conditions, a deployment instruction for the smart bus stop is triggered. In response to the deployment instruction, a recommended deployment location and a corresponding deployment scenario identifier are generated. The recommended deployment location and the corresponding deployment scenario identifier are then pushed to the operation and maintenance terminal so that operation and maintenance personnel can deploy new smart bus stops according to the recommended deployment location. The preset deployment conditions are that the number of travel query requests or the number of unfulfilled travel needs in the preset area obtained from the external platform exceeds a threshold for a consecutive preset period, and there are no smart bus stops deployed in the preset area.

[0121] The migration instructions in this step and step S402 form a dual logic: migration solves the problem of "where passenger flow is low and needs to be withdrawn", and deployment solves the problem of "where demand is high and needs to be deployed".

[0122] It should be noted that the passenger flow data is not limited to the ticket purchase records of the bus stop itself, but also includes the number of travel query requests and the number of unfulfilled requests within the preset area obtained from external platforms (such as customized bus mobile applications, urban traffic big data platforms, etc.).

[0123] The number of travel query requests refers to the behavioral data generated by passengers searching for routes, checking timetables, and saving stations in the application. This data reflects potential travel demand. The number of unfulfilled travel requests refers to the records of passengers who initiated travel queries or reservation requests in the application but failed to complete ticket purchases due to the lack of suitable routes or insufficient seats. These records directly reflect travel demand that cannot be met by existing transportation capacity. The system continuously acquires the above data from external platforms and aggregates and analyzes it according to deployment scenario identifiers (such as commuter shuttles, hospital shuttles, campus shuttles, etc.).

[0124] When the number of travel query requests or unfulfilled travel requests within a preset area for a consecutive preset period (e.g., 15 consecutive days) exceeds a preset threshold (e.g., an average of 50 queries per day or 10 unfulfilled travel requests per day), and there are currently no smart bus stop signs deployed in that preset area, the system determines that the preset deployment conditions are met and automatically triggers a deployment command. In response to this command, the system generates a recommended deployment location (e.g., output as coordinates "30°32′N, 114°18′E") based on the starting cluster center of the unfulfilled travel requests or the geographical distribution heatmap peaks of the travel query requests, and automatically matches the corresponding deployment scenario identifier based on the main travel purpose of the area (e.g., the destination types that frequently appear in the query requests).

[0125] Furthermore, the system will push recommended deployment locations and scenario identifiers to the terminal devices of maintenance personnel (such as mobile applications or management backends). Maintenance personnel can then carry the new smart bus stop signs to the site to complete the deployment based on the recommended information. This allows for the pre-deployment of service nodes in areas where demand has formed but supply has not yet covered, enabling refined bus stop scheduling from passively responding to current passenger flow to proactively anticipating future demand. Through the setting of these preset deployment conditions, bus stop scheduling decisions are no longer limited to post-evaluation of already deployed signs, but can be proactively planned based on comprehensive travel data, further enhancing the adaptability of customized bus services to dynamic travel demands.

[0126] Step A304: The scene acoustic model, the bus route database, and the interaction mode are remotely updated using an OTA upgrade algorithm.

[0127] After a bus stop is moved to a new location, or even during daily operations, the operator may want to upgrade the software capabilities of the bus stop. This application supports OTA (Over-The-Air) algorithm upgrades, eliminating the need for maintenance personnel to physically remove or replace storage cards or hardware. OTA upgrades receive software iteration packages pushed by the operator via 4G / 5G networks, updating three core elements: the scene acoustic model (adapting to the noise environment and dialects in the new scene), the bus route database (updating routes and timetables), and the interaction mode (such as detailed adjustments to the age-appropriate interface).

[0128] In one implementation, step A304 includes steps A3041 to A3043:

[0129] Step A3041: Based on the OTA upgrade algorithm, receive the incremental algorithm package from the operator. The incremental algorithm is generated based on the aggregation training of multi-site conflict samples. The multi-site conflict samples are the aggregated data of each station sign after clustering according to the deployment scenario identifier.

[0130] It should be noted that the operator does not push the complete model file every time, but rather pushes incremental algorithm packages, which only contain the changes from the old model to the new model, thereby reducing network transmission volume (possibly from tens of MB to a few MB).

[0131] Conflicting samples refer to inconsistent interpretations of the same travel request by different bus stop signs. For example, a passenger saying "to the city hospital" at stop A is interpreted as "City A First Hospital"; the same passenger saying the same thing at stop B is interpreted as "City A Second Hospital". The bus stop signs report these inconsistencies to the dispatch platform. The operator clusters these conflicting samples according to deployment scenario identifiers (e.g., hospital scenario, commercial district scenario, school scenario), and then trains incremental parameters separately for each scenario. For example, after clustering, it is found that in the hospital scenario, "city hospital" should be preferentially interpreted as the nearest municipal hospital, while in the commercial district scenario, "city hospital" might refer to a fixed-name commercial complex, "City Hospital Building". The incremental algorithm package trained based on aggregated data can specifically improve the interpretation accuracy for each scenario.

[0132] Step A3042: Verify the version compatibility and digital signature validity of the incremental algorithm package. After successful verification, hot-load the module into memory and update the scene acoustic model, the bus route library, and the interaction mode.

[0133] After receiving the incremental algorithm packet, the bus stop sign performs security verification. Version compatibility check: Ensures the difference between the target version of the incremental packet and the currently running version is continuous and cannot span multiple major versions, otherwise errors are likely. Digital signature validity: The incremental packet is signed with the operator's private key, and the bus stop sign uses its public key to verify the signature, ensuring the packet has not been tampered with and originates from a trusted source.

[0134] After successful verification, the system loads modules as follows: scene acoustic model update module, bus route database update module, and interaction mode configuration update module. Hot loading refers to loading the new model parameters into memory via dynamic link libraries without restarting the entire operating system, and atomically replacing the old model pointers. For example, after the new acoustic model is loaded, the speech recognition thread will switch to the new model after a short silence, without interrupting the ongoing dialogue. After loading is complete, the old model is released from memory.

[0135] In step A3043, during the update, the scene acoustic model retains the baseline parameters of the historical dialect offset dictionary, and the bus route database is simultaneously refreshed with the historical touch hotspot data of each station.

[0136] During the update process: First, when updating the scenario acoustic model, the original model cannot be completely overwritten, and the baseline parameters of the historical dialect offset dictionary must be retained. This is because the bus stop sign may have accumulated adaptability to local special dialects through incremental learning during operation. For example, the bus stop sign is located in City A, and through a large number of interactions, it has learned the local tonal variation pronunciation of the character "六" in the phrase "去六渡桥". If it is directly replaced with a new model, these learned dialect features will be lost. Therefore, when the OTA algorithm loads the new acoustic model, it extracts the baseline parameters of the dialect offset dictionary from the old model and merges them into the new model.

[0137] Second, when updating the bus route database, the historical touch hot zone data of each station needs to be refreshed synchronously. Because after the route database is changed, the positions of the frequently used destination buttons displayed on the screen of the bus stop sign may change. If the hot zone data is not refreshed synchronously, the old touch hot zone mapping will point to the wrong route. For example, the original "Go to Railway Station" button is in the upper left corner of the screen, and after the route database is updated, the button moves to the lower right corner, but the hot zone data still records the coordinates of the upper left corner, resulting in no response or incorrect response when the passenger clicks the upper left corner. Therefore, while the system loads the new route database, it clears and regenerates the hot zone data based on the new interface layout to ensure the accuracy of touch interaction. These two retention and synchronization mechanisms jointly ensure that the user experience after OTA upgrade does not degrade.

[0138] During the OTA upgrade process, the update of the interaction mode is based on deep clustering and incremental learning of passenger behavior features in multi-station conflict samples, so as to realize the adaptive evolution of the interaction strategy. Specifically, interaction conflict samples are collected from each bus stop sign, that is, comparative data of the time required for the same passenger to complete ticket purchase, error rate, and number of retries under different interaction modes. For example, the historical data of a certain bus stop sign shows that when the "aging-friendly mode" is enabled, the average ticket purchase duration of passengers over 65 years old drops from 90 seconds to 25 seconds, while ordinary adult passengers in this mode have a 10% drop in operation efficiency due to excessively large buttons and too low information density. These samples are clustered according to deployment scene identifiers (such as hospitals, vegetable markets, and schools), and input into the interaction mode decision tree for incremental training.

[0139] The incremental algorithm package pushed via OTA includes updated decision rules: for example, if the proportion of elderly users identified by a bus stop sign in the past 7 days (inferred from the difference in confidence between voice and touch in step S1034) exceeds 40%, and the average ticket purchase time is higher than 45 seconds, the default interaction mode will be automatically switched from "standard mode" to "age-friendly mode," and the switching threshold will be dynamically lowered from 50% to 35%. Furthermore, the update package can also carry "interaction mode fusion parameters," enabling the bus stop sign to mix modes for different input channels of the same passenger. For example, for elderly people with low voice confidence but accurate touch, only the touch area is enlarged and the interface hierarchy is simplified, while retaining standard-speed voice feedback, rather than enabling slow-speed broadcasting across the board. Through OTA remote updates, the interaction mode changes from a static configuration to a dynamic strategy that can continuously optimize itself as the user group shifts, thereby continuously improving ticket purchase efficiency and satisfaction for different groups in various scenarios without replacing hardware.

[0140] It should be noted that alternative solutions exist for the customized bus travel method based on smart bus stop signs, which can achieve the same purpose as the invention. In terms of partial improvements, the 4G / 5G and Wi-Fi dual-mode communication module can be replaced with a LoRa wireless communication module to adapt to areas with weak signals and reduce communication costs; the mains power and solar backup power supply can be replaced with pure solar power supply and equipped with a large-capacity lithium battery for energy storage, suitable for temporary stations without mains power; a card payment function can be added to the existing QR code ticketing system, supporting direct payment by bus card or bank card, convenient for those who do not use smartphones; the mobile base with braked casters can be replaced with a foldable base, reducing the transportation and storage volume while retaining mobility. In terms of overall architecture replacement, a portable smart terminal + temporary base station solution can be adopted. The compact portable terminal replaces the standing bus stop sign, and is paired with a temporary base station responsible for communication. It also has the functions of touch interaction, voice recognition, QR code ticket purchase and information synchronization. It does not require a large bracket, has lower cost and more flexible deployment. It is especially suitable for short-term temporary shuttle scenarios such as exhibitions and events, and can fully realize the invention purpose of convenient ticket purchase for passengers, accurate passenger pick-up for drivers and flexible adjustment of stations.

[0141] Example 2

[0142] Based on the same inventive concept, embodiments of the present invention also provide a customized public transportation device based on a smart bus stop sign, such as... Figure 3 As shown, it includes:

[0143] The data parsing module 10 is used to obtain passengers' travel needs and match the location information of smart bus stops according to the travel needs;

[0144] The information synchronization module 20 is used to generate waiting information based on the travel information and the location information of the smart bus stop and synchronize it to the on-board terminal of the corresponding customized bus. The on-board terminal generates the estimated arrival time of the customized bus based on the waiting information. The waiting information includes at least the location of the smart bus stop, the number of passengers, and the travel time requirement.

[0145] The information feedback module 30 is used to provide the passenger with the location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal.

[0146] In this embodiment of the invention, the customized bus travel device based on smart bus stop signs is a device corresponding to the customized bus travel method based on smart bus stop signs provided in Embodiment 1 above. Its specific implementation can be referred to the detailed description of the customized bus travel method based on smart bus stop signs in Embodiment 1 above. In this embodiment of the invention, it will not be repeated here.

[0147] Example 3

[0148] Based on the same inventive concept, embodiments of the present invention also provide a smart bus stop sign, which includes at least: a display module, a communication module, a control module, a positioning module, and a mobility module, wherein:

[0149] The control module is connected to the display module, the communication module, the positioning module, and the motion module, respectively.

[0150] The mobile module includes a main support and a mobile base. The main support is a vertical shell structure of the smart bus stop sign, used to support and fix the hardware equipment. The mobile base is installed at the bottom of the main support.

[0151] The control module includes a memory and a processor. The memory stores a computer program, and the processor executes the customized public transportation method based on smart bus stop signs.

[0152] The principles by which the above-described devices, smart bus stop signs, and systems in the embodiments of the present invention solve the problem are similar to those of the aforementioned methods. Therefore, their implementation can refer to the implementation of the aforementioned methods, and repeated details will not be repeated.

[0153] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0154] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0155] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0156] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in the flowcharts and block diagrams.

[0157] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of equivalents of this invention, this invention is also intended to include these modifications and variations.

Claims

1. A customized public transportation method based on smart bus stop signs, characterized in that, include: Obtain passengers' travel needs and match smart bus stop location information based on those needs; Based on the travel information and the location information of the smart bus stop, waiting information is generated and synchronized to the on-board terminal of the corresponding customized bus. The on-board terminal generates the estimated arrival time of the customized bus based on the waiting information. The waiting information includes at least the location of the smart bus stop, the number of passengers, and the travel time requirement. The location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal are provided to the passenger.

2. The customized bus travel method based on intelligent bus stop signs according to claim 1, characterized in that, The process of obtaining passengers' travel needs and matching smart bus stop location information based on those needs includes: Obtain the real-time geographic coordinates and deployment scenario identifier of the current bus stop sign. The deployment scenario identifier is used to distinguish the service scenarios of different buses. Collect passengers' travel needs via voice or touch input; Using the real-time geographic coordinates and the deployment scenario identifier as contextual constraints, the travel demand is fused with dual-channel semantic features to generate a structured travel intent; Based on the spatial distance between the destination in the structured travel intention and the real-time geographic coordinates, the final location information of the smart bus stop is obtained.

3. The customized bus travel method based on intelligent bus stop signs according to claim 2, characterized in that, The step of using the real-time geographic coordinates and the deployment scenario identifier as context constraints to perform dual-channel semantic feature fusion on the travel demand to generate a structured travel intent includes: Based on the deployment scenario identifier, the corresponding scenario acoustic model is invoked to perform microphone array beamforming noise reduction and dialect phoneme correction on the travel needs of the voice input, so as to obtain standard speech features; Historical touch hotspot data is retrieved based on the real-time geographic coordinates to predict the interaction path of the travel demand based on the touch input and obtain standard touch features. Based on the standard voice features and the standard touch features, incremental learning is performed on the deployment scenario identifier to generate the final structured travel intent; The user type is inferred by the difference between the confidence levels of the standard voice features and the standard touch features, so as to switch the corresponding interaction mode.

4. The customized bus travel method based on intelligent bus stop signs according to claim 1, characterized in that, Before the process of generating waiting information based on the travel information and the smart bus stop location information and synchronizing it to the onboard terminal of the corresponding customized bus, it also includes: Based on the destination information and the real-time geographic coordinates of the current bus stop, a bus route database is retrieved with the real-time geographic coordinates as the starting point and the destination information as the ending point to obtain candidate routes. The bus route database is generated in real time based on passenger flow statistics for each stop. Based on the passengers' desired departure time and the number of people traveling with them, the candidate routes are sorted under multi-objective constraints to generate the optimal ticket purchase plan. The optimal ticketing plan is bound to the real-time geographic coordinates to generate a unique ticketing identifier code, and a QR code generation process is used for the passenger to confirm the ticket purchase.

5. The customized bus travel method based on intelligent bus stop signs according to claim 4, characterized in that, The step of sorting the candidate routes under multi-objective constraints based on the passenger's desired departure time and number of companions to generate the optimal ticketing plan includes: The waiting time is determined based on the passenger's expected departure time, and the seat availability rate is determined based on the number of passengers traveling with the passenger. The waiting time and the seat availability rate are then weighted and merged to generate a priority score. If the number of people traveling together is greater than the number of seats available on a single route, then the number of people traveling together is split into multiple subgroups, and each subgroup is matched with the available seats of the same or adjacent trains to generate a collaborative ticketing plan. If there are no direct routes with sufficient seats available during the desired departure time, then search for nearby stations within a preset radius, retrieve passenger data for ride-sharing, perform destination similarity matching and route merging feasibility calculation, and generate a route merging and fare sharing scheme. The optimal ticketing scheme is the combination of the route with the highest priority score, the collaborative ticketing scheme or the merged route, and the fare sharing scheme.

6. The customized bus travel method based on intelligent bus stop signs according to claim 1, characterized in that, The process of generating waiting information based on the travel information and the location information of the smart bus stop, and then synchronizing it to the onboard terminal of the corresponding customized bus, includes: Based on the travel information and the location information of the smart bus stop sign, extract the waiting information corresponding to the unique ticket purchase identifier; The waiting information is synchronized to the onboard terminal of the corresponding customized bus through a dual-mode communication channel.

7. The customized bus travel method based on intelligent bus stop signs according to any one of claims 1 to 6, characterized in that, After providing the passenger with the location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal, the method further includes: Collect station passenger flow data at the waiting point location, including the number of ticket purchases and the distribution of passengers' destinations and time periods; If the passenger flow data of the station meets the preset migration conditions, the migration command of the smart bus stop is triggered, and in response to the migration command, the bottom universal wheels of the bus stop are unlocked and pushed to the new station, and the real-time geographic coordinates and deployment scene identifiers are updated to adapt to the service scene of the new station. The preset migration conditions are that the average daily passenger flow is lower than a threshold within a consecutive preset period. If the passenger flow data of the station meets the preset deployment conditions, a deployment instruction for the smart bus stop is triggered. In response to the deployment instruction, a recommended deployment location and a corresponding deployment scenario identifier are generated and pushed to the operation and maintenance terminal so that operation and maintenance personnel can deploy new smart bus stops according to the recommended deployment location. The preset deployment conditions are that the number of travel query requests or the number of unfulfilled travel needs in the preset area obtained from the external platform exceeds a threshold for a consecutive preset period, and there are no smart bus stops deployed in the preset area. The scene acoustic model, the bus route database, and the interaction mode are remotely updated using an OTA upgrade algorithm.

8. The customized bus travel method based on intelligent bus stop signs according to claim 7, characterized in that, The method of remotely updating the scene acoustic model, the bus route database, and the interaction mode through an OTA upgrade algorithm includes: Based on the OTA upgrade algorithm, the incremental algorithm package is received from the operator. The incremental algorithm is generated by training on the aggregation of multi-site conflict samples. The multi-site conflict samples are the aggregated data of each station sign after clustering according to the deployment scenario identifier. Verify the version compatibility and digital signature validity of the incremental algorithm package. After verification, hot-load the module into memory and update the scene acoustic model, the bus route library, and the interaction mode. During the update, the scene acoustic model retains the baseline parameters of the historical dialect offset dictionary, and the bus route database is updated synchronously with the historical touch hotspot data of each station.

9. A customized public transportation device based on a smart bus stop sign, characterized in that, include: The data parsing module is used to obtain passengers' travel needs and match the location information of smart bus stops based on these travel needs. The information synchronization module is used to generate waiting information based on the travel information and the location information of the smart bus stop and synchronize it to the on-board terminal of the corresponding customized bus. The on-board terminal generates the estimated arrival time of the customized bus based on the waiting information. The waiting information includes at least the location of the smart bus stop, the number of passengers, and the travel time requirement. The information feedback module is used to provide the passenger with the location information of the smart bus stop sign and the estimated arrival time fed back by the vehicle terminal.

10. A smart bus stop sign, characterized in that, The intelligent bus stop sign includes at least: a display module, a communication module, a control module, a positioning module, and a mobility module, wherein: The control module is connected to the display module, the communication module, the positioning module, and the motion module, respectively. The mobile module includes a main support and a mobile base. The main support is a vertical shell structure of the smart bus stop sign, used to support and fix the hardware equipment. The mobile base is installed at the bottom of the main support. The control module includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the customized public transportation method based on intelligent bus stop signs as described in any one of claims 1 to 8.