Subway information broadcasting method based on time period scheduling

Abstract

The present application relates to the technical field of subway information broadcast control, and discloses a subway information broadcast control method based on time period scheduling. The method comprises the following steps: collecting multi-source monitoring data of the subway operation environment in real time, covering passenger flow data, train arrival data and emergency event reporting data; dividing the current operation cycle into multiple continuous time slices based on a preset time period division rule, and generating a corresponding time period identification code for each time slice; matching a target broadcast control template from a broadcast control strategy library according to the time period identification code, and dynamically filling parameters of the target broadcast control template in combination with the multi-source monitoring data; performing logical verification on the target broadcast control template after parameter filling, triggering a broadcast control decision reconstruction process when the verification is abnormal, and generating an executable broadcast control instruction set when the verification is normal. This method dynamically adapts to the operation requirements of different time periods, improves the accuracy and timeliness of subway information broadcast control, and optimizes the passenger travel experience and operation efficiency.

Description

Technical Field

[0001] This invention relates to the field of subway information broadcasting and control technology, specifically a subway information broadcasting and control method based on time-slot scheduling. Background Technology

[0002] With the continuous expansion of urban public transportation networks, the quality of information broadcasting and control during subway operation, as a high-capacity and high-efficiency mode of transportation, directly affects passengers' travel experience and operational safety. Currently, subway information broadcasting and control mostly adopts a fixed time period or manual intervention mode, which is difficult to adapt to the complex and ever-changing operating environment.

[0003] In terms of passenger flow, there is a significant difference in passenger density between peak and off-peak hours, and fixed broadcast content cannot meet the information needs of different times. For example, during peak hours, passengers are more concerned about real-time information such as train congestion and transfer guidance, while during off-peak hours they may need more information on services around stations. Existing systems often fail to adjust broadcast control strategies in a timely manner, resulting in key information being overwhelmed by redundant content, affecting information transmission efficiency.

[0004] The dynamic changes in train operation status also pose challenges to the broadcast control system. Train delays and temporary adjustments to station stops occur frequently, and if broadcast control information is not updated in sync, it can easily cause confusion or even panic among passengers. The traditional method of relying on manual entry of changed information is not only slow to respond but also carries the risk of human error.

[0005] Information dissemination is particularly crucial in emergency situations. In the event of emergencies such as fires or equipment malfunctions, it is essential to quickly send evacuation instructions and rescue progress information to passengers. However, existing broadcast control systems lack a tiered response mechanism for different types of emergencies, often resulting in information overload or missing key information, thus delaying emergency response.

[0006] Insufficient integration and utilization of multi-source monitoring data has resulted in a lack of data support for broadcast control strategies. Data such as passenger flow, train location, and equipment status are scattered across different systems, making real-time correlation analysis impossible and hindering the accurate determination of information needs priorities for different time periods, thus wasting broadcast control resources. Summary of the Invention

[0007] The purpose of this invention is to provide a subway information broadcasting and control method based on time period scheduling to solve the problems mentioned in the background art.

[0008] To achieve the above objectives, the present invention provides a subway information broadcasting control method based on time-slot scheduling, the method comprising:

[0009] Step 1: Collect multi-source monitoring data of the subway operating environment in real time. The multi-source monitoring data includes passenger flow data, train arrival data, and emergency event reporting data.

[0010] Step 2: Divide the current operating cycle into multiple consecutive time slices based on the preset time period division rules, and generate a corresponding time period identifier code for each time slice;

[0011] Step 3: Match the target broadcast control template from the broadcast control strategy library according to the time period identifier code, and dynamically fill the parameters of the target broadcast control template based on the multi-source monitoring data;

[0012] Step 4: Perform logical verification on the target broadcast control template after parameter filling. If the verification fails, trigger the broadcast control decision reconstruction process. If the verification is normal, generate an executable broadcast control instruction set.

[0013] Preferably, the real-time acquisition of multi-source monitoring data of the subway operating environment in step 1 includes:

[0014] Passenger flow data, train arrival data, and emergency event reporting data are collected synchronously through the gate counting unit, train positioning unit, and dispatch console event recording unit, respectively.

[0015] An independent data cache partition is established for each type of data. The passenger flow data is stored in the first cache partition, the train arrival data is stored in the second cache partition, and the emergency event reporting data is stored in the third cache partition in the order of timestamps.

[0016] When any data cache partition reaches a preset data volume threshold, the data within the partition is uploaded to the central data pool in a time frame sequence.

[0017] Preferably, step 2, which involves dividing the time slices based on a preset time period division rule, includes:

[0018] Historical passenger flow fluctuation curves for the same period are extracted from the central data pool to identify the dividing points between peak, off-peak, and trough periods.

[0019] The current operating cycle is divided into segments based on the defined time points, generating a time period sequence that includes at least peak period segments, off-peak period segments, and low-peak period segments;

[0020] Each time slice is assigned a unique time slice identifier code, which includes the time slice type code and the start timestamp.

[0021] Preferably, step 3, matching the target broadcast control template and filling in the parameters, includes:

[0022] Match the time period type code in the time period identifier with the template index of the broadcast control strategy library to output the basic broadcast control template;

[0023] Real-time acquisition of instantaneous passenger flow, train arrival delay duration, and emergency event level coefficient within the current time slice;

[0024] The instantaneous passenger flow value is filled into the broadcast frequency parameter of the basic broadcast control template, the train arrival delay duration is filled into the voice prompt duration parameter, and the emergency event level coefficient is filled into the content priority parameter.

[0025] Preferably, step 4 involves logically verifying the target broadcast control template after parameter filling, including:

[0026] Check whether the broadcast frequency parameter exceeds the preset frequency threshold range corresponding to the type code of this time period;

[0027] Compare the spatial matching degree between the voice prompt duration parameter and the real-time train location data;

[0028] Verify whether the mapping relationship between the content priority parameter bits and the level of emergency event reporting data meets the preset emergency response rules.

[0029] Preferably, when a verification anomaly triggers the broadcast control decision reconstruction process, the following is executed:

[0030] Extract the parameter bits of the verification exception and their associated data source, and generate an exception type identifier;

[0031] Match associated decision nodes in the decision reconstruction network based on the anomaly type identifier, and select a dynamic adjustment coefficient among the associated decision nodes based on the remaining duration of the current time slice;

[0032] The correction value of the abnormal parameter bit is recalculated using the aforementioned dynamic adjustment coefficient, and the original filling value is replaced.

[0033] Preferably, when generating an executable broadcast control instruction set, the following is included:

[0034] After parsing the target broadcast control template with the filled parameters, audio output instructions, display terminal update instructions, and emergency broadcast channel selection instructions are separated.

[0035] Configure sound pressure level adjustment parameters for audio output commands, configure multi-screen synchronization delay parameters for display terminal update commands, and configure priority coverage flags for emergency broadcast channel selection commands.

[0036] Preferably, the method further includes:

[0037] During the execution of audio output commands, the noise level in the station hall is collected in decibels in real time;

[0038] When the noise decibel value exceeds the noise tolerance threshold corresponding to the current time period type code, the output gain value of the sound pressure level adjustment parameter is automatically increased according to the difference ratio.

[0039] When the noise decibel value remains below the noise tolerance threshold for a preset duration, the output gain value is gradually reduced.

[0040] Preferably, after step 4, the method further includes:

[0041] Record the execution result data of each broadcast control command, including command response delay, changes in passenger dwell time, and equipment energy consumption increment;

[0042] The execution result data is bound to the corresponding time period identifier code and stored in the strategy optimization library for updating the parameter threshold mapping relationship in the broadcast control strategy library.

[0043] Preferably, the update process of the strategy optimization library includes:

[0044] Extract the historical execution result data sequence of the same time period identifier code, and calculate the volatility of instruction response delay, the trend coefficient of passenger dwell time change, and the load gradient of equipment energy consumption increment;

[0045] When the volatility exceeds the preset stability threshold, the baseline value of the voice prompt duration parameter corresponding to the time period identifier is adjusted.

[0046] When the trend coefficient shows a continuous negative offset, the upper limit value of the broadcast frequency parameter corresponding to the identification code of that period is recalibrated;

[0047] The screen refresh rate parameter of the display terminal update command is dynamically compressed according to the load gradient.

[0048] Compared with the prior art, the beneficial effects of the present invention are:

[0049] By collecting multi-source monitoring data in real time, a comprehensive understanding of the subway's operational status has been achieved. The immediate acquisition of data such as passenger flow, train arrivals, and emergency events allows the broadcast control system to keenly capture dynamic changes in the operating environment, providing valuable information for subsequent information dispatching.

[0050] Dividing the current operational cycle into multiple consecutive time slices and generating corresponding time-segment identifiers makes the formulation of broadcast control strategies more targeted. Different time periods have different operational characteristics; by dividing the cycle into time slices, the complex operational cycle can be broken down into several units with similar characteristics. This facilitates matching each unit with an appropriate broadcast control template, avoiding the rigidity of traditional fixed broadcast control models when dealing with time-segment changes.

[0051] The system matches target broadcast control templates from the broadcast control strategy library based on time period identifiers and dynamically fills in parameters using multi-source monitoring data, thereby improving the accuracy of information broadcast control. The broadcast control templates provide the foundation for the information presentation framework, while the dynamic parameter filling assigns specific content to the templates based on real-time operational data, enabling broadcast control information to closely align with current passenger needs, train status, and emergency situations, making the information obtained by passengers more practical.

[0052] Logical verification of the target broadcast control template after parameter filling ensures the validity of broadcast control instructions. The verification process promptly identifies potential logical inconsistencies and parameter errors within the template. By triggering a broadcast control decision refactoring process, it ensures that the final generated executable broadcast control instruction set is logically consistent and accurate. This step reduces operational chaos caused by information errors and enhances the reliability of the broadcast control system.

[0053] In emergency scenarios, this method demonstrates unique advantages. Emergency event reporting data is incorporated into the multi-source monitoring data scope, and emergency information can be prioritized when matching broadcast control templates and filling parameters. Combined with time-slice scheduling, broadcast control strategies can be quickly adjusted within specific time periods of an emergency, and key emergency information can be centrally pushed out, helping passengers respond to emergencies in an orderly manner and maintaining operational order.

[0054] The integration and application of multi-source data, combined with time-slice scheduling, optimizes the allocation of broadcast control resources. By analyzing monitoring data from different time slices, the key information needs of each time period can be identified, thereby rationally allocating broadcast control resources and preventing irrelevant information from occupying the dissemination channels. During peak hours, the focus is on content such as train transfers and congestion alerts, while during off-peak hours, more convenient service information is added, making efficient use of limited broadcast control resources.

[0055] The implementation of this method has driven a shift in subway information broadcasting control from passive response to proactive prediction. Through continuous monitoring and dynamic adjustment, the broadcasting control system can prepare broadcasting control plans in advance for upcoming time slices based on historical data and real-time conditions, shortening the response time for information release, allowing passengers to obtain relevant information earlier, and improving their travel experience. Attached Figure Description

[0056] Figure 1 This is a schematic diagram illustrating the working principle of the subway information broadcasting and control method based on time-slot scheduling as described in this invention.

[0057] Figure 2 A flowchart for time slice division and time period identifier code generation;

[0058] Figure 3 A flowchart for broadcast control template matching and dynamic parameter filling;

[0059] Figure 4A flowchart for generating an executable broadcast control instruction set;

[0060] Figure 5 A flowchart for recording and storing broadcast control execution results. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] Please see Figure 1 This invention provides a subway information broadcast control method based on time-slot scheduling, the method comprising:

[0063] The system collects multi-source monitoring data of the subway operating environment in real time, including passenger flow data, train arrival data, and emergency event reporting data. Based on preset time period division rules, the current operating cycle is divided into multiple continuous time slices, and a corresponding time period identifier code is generated for each slice. A target broadcast control template is matched from the broadcast control strategy library based on the time period identifier code, and parameters are dynamically populated into the target broadcast control template based on multi-source monitoring data. The target broadcast control template after parameter population is logically verified. If verification fails, a broadcast control decision reconstruction process is triggered; if verification is successful, an executable broadcast control instruction set is generated.

[0064] Example 1: See Figure 2 During the multi-source monitoring data collection process of the subway operating environment, the turnstile counting unit uses infrared sensors to count the number of passengers passing through each entrance and exit channel in real time. Each turntile opening and closing action generates a passenger flow record with a millisecond-level timestamp. The train positioning unit, based on data interaction between trackside beacons and onboard transponders, uploads the distance data between the train and the next station twice per second, and calculates the estimated arrival time to the second based on a preset operating speed model. The dispatcher's event recording unit receives manually entered emergency event reports. Event types include equipment failure, passenger flow abnormality, and safety incidents. Each report is automatically appended with the dispatcher ID and submission timestamp. The three types of data are transmitted to independent data cache partitions: passenger flow records are stored in the first cache partition in ascending order of timestamp, and the data structure includes the turnstile number, direction of passage, and passenger count; train arrival data is stored in the second cache partition, and the data structure includes the train number, entry track number, and estimated delay time; emergency event reports are stored in the third cache partition, and the data structure includes the event type code, impact range, and urgency level rating.

[0065] When the number of records in the first cache partition reaches 1000, the system automatically encapsulates this batch of data into a time frame sequence, with the frame header marked with the start timestamp and the number of records, and uploads it to the passenger flow database table in the central data pool via a dedicated network channel. Similarly, when the second cache partition accumulates 1000 train records, a data frame containing the train position coordinate sequence is generated and uploaded to the train operation database table. The third cache partition triggers an upload when it reaches 1000 event reports, with the event data frame including a dispatcher number identifier. The central data pool adopts a columnar storage structure, with the passenger flow table stored by hour, the train operation table by line, and the event report table by event type.

[0066] When the time-segmentation process begins, the central data pool extracts historical data from the same workday for the past 30 days from the passenger flow table and aggregates passenger flow data in 10-minute granularity. A sliding window algorithm is used to calculate the passenger flow change rate at each time point. When the change rate exceeds 5% per second for three consecutive time points, that time point is marked as a passenger flow inflection point. For example, if the passenger flow change rate jumps from 3% per second to 7% per second at 07:15, it is determined as the transition point from trough to peak; if the change rate drops from 6% per second to 2% per second at 19:30, it is marked as the transition point from peak to trough. Based on the inflection point sequence identified throughout the day, the operating cycle is divided into multiple time-segment slices: 06:00-07:15 is classified as the low-peak period, 07:15-09:30 as the peak period, 09:30-16:00 as the off-peak period, etc. Each time-segment generates a unique identifier code, encoded as "time-segment type_start time," for example, "PEAK_071500" indicates a peak period starting at 07:15:00. The time period type is coded using letters: PEAK for peak hours, NORM for off-peak hours, and LOW for low-peak hours.

[0067] During data caching, the first cache partition employs a circular buffer structure. When the write pointer reaches the 1000th slot, data upload is triggered, and the write pointer is simultaneously reset to the beginning of the buffer. The second cache partition uses a double-buffering mechanism: while the foreground buffer is writing, the background buffer performs data upload, avoiding data transmission blocking real-time data collection. The third cache partition sets up a priority queue, allowing event reports with an urgency rating of Level 1 to be transmitted in the queue, without being subject to the 1000-report limit. When the historical passenger flow analysis module of the central data pool performs inflection point detection, a weighted moving average algorithm is used to eliminate abnormal fluctuations on a single day, and the inflection point time accuracy is calibrated to the minute level. After the time period identifier code is generated, it is stored in the metadata registry, which also records the duration of the time period and the list of associated physical sites.

[0068] During the construction of the time-segment sequence, a 5-minute overlap zone is set between adjacent time-segment slices. For example, 07:10-07:15 is a transition period, during which both off-peak and peak-peak time-segment identifiers exist. Data processing during the transition period employs a dual strategy: passenger flow data participates in the statistical calculations of both periods simultaneously, while train arrival data is processed according to the target time-segment strategy. The start timestamp in the time-segment identifier uses the ISO8601 format, accurate to the millisecond level, for example, "20240903T071500.000+0800". When the operation plan is adjusted, the system automatically compares the timetable change records and dynamically splits or merges the generated time-segment slices. For example, if a peak period originally scheduled to end at 08:00 is extended to 08:30 due to temporary train additions, the time-segment corresponding to the original identifier "PEAK_070000" automatically extends its end time and generates a new off-peak time-segment "PEAK_073000".

[0069] The data upload mechanism includes an exception handling process: when the network is interrupted, the cache partition starts local persistent storage, writing to the solid-state drive every 100 new records, and retransmitting them in chronological order after the network is restored. The central data pool performs CRC checks on received data frames; data frames that fail the check trigger the incremental retransmission mechanism of the corresponding cache partition. The time period segmentation task is executed automatically once per hour, locking the historical data query range to the most recent 30 calendar days (excluding holiday data) each time. The inflection point detection algorithm uses an adaptive threshold: a 5% change rate threshold per second on weekdays and 3% per second on weekends. The generated time period sequence takes effect only after manual confirmation; otherwise, the previous period segmentation scheme is used.

[0070] In the time slot identifier code allocation process, the system maintains a globally unique verification mechanism. When a newly generated identifier code is detected to conflict with an existing identifier code, a sequence number is automatically appended to the end of the code, for example, changing "PEAK_071500" to "PEAK_071500_01". The time slot type code library supports dynamic expansion. When a new passenger flow pattern is detected (such as the exit period of a large event), a new "EVENT" type code can be added and a dedicated broadcast control strategy can be configured. Each time slot slice is associated with a multi-dimensional feature vector, including attributes such as average passenger flow, maximum congestion, and typical event type. These attribute values ​​are generated during slice creation by real-time analysis of historical data from the previous three similar time slots.

[0071] The time-slot type coding system features an emergency event linkage mechanism. When the dispatch console's event recording unit uploads an emergency event report (emergency level rating ≥ 7), the system automatically triggers the process of appending an emergency identifier to the time-slot code. It parses the currently effective time-slot identifier code (e.g., "PEAK_073000"), appends the "EMG" emergency identifier to the end of the code, and generates a temporary emergency time-slot code "PEAK_073000_EMG". The temporary emergency time-slot code takes precedence over the original time-slot code. The system locks this code through the emergency identifier field in the metadata registry and forcibly calls the emergency-specific template in the broadcast control strategy library (e.g., "TPL_EMG_PEAK_V3"). This template masks conventional information (such as site-related services) and retains only three core contents: event type, evacuation guidance, and rescue progress. After the emergency event is resolved (the dispatch console uploads "Event Status = Resolved"), the system automatically deletes the "EMG" identifier, restores the original time-slot identifier code and the conventional template call, and retains the emergency time-slot code for 24 hours for post-event traceability.

[0072] The cache partition management employs an intelligent cleanup strategy: the first cache partition is cleared immediately after successful data upload; the second cache partition retains data from the most recent two hours for train delay analysis; and the third cache partition retains event reports for 24 hours for post-event traceability. A time-slice version management system is established in the central data pool. Each time time-slice division is adjusted, a new version number is generated, and the old version slice is converted to read-only status for auditing purposes. Time-slice identifiers require validity verification during actual use. The system automatically filters out expired identifiers (those corresponding to time-slice ends earlier than the current time) and activates the next time-slice identifier in real time.

[0073] Example 2: See Figure 3 The matching process between the time slot type code in the time slot identifier and the template index in the broadcast control strategy library is implemented through a distributed query engine. When the system obtains the current time slot identifier "PEAK_073000", the query engine parses out the time slot type code "PEAK" and uses it as the primary key to search in the template index table of the broadcast control strategy library. The template index table is stored in a B+ tree structure, with leaf nodes storing the template number, version number, and storage path. After a successful match, the system loads the basic broadcast control template numbered "TPL_PEAK_V3" from the template storage area. This template is a structured document in XML format, containing three parameter placeholders: {FREQ} corresponds to the broadcast frequency parameter, {DUR} corresponds to the voice prompt duration parameter, and {PRI} corresponds to the content priority parameter.

[0074] Broadcast control strategy library indexing rules: The broadcast control strategy library adopts a two-dimensional indexing structure of time period type encoding + site level. In addition to storing the template number and version number, the B+ leaf nodes of the template index table are also associated with the site level identifier ("TRAN" for transfer stations, "COM" for ordinary stations, and "HUB" for hub stations). For example, if the current time period identifier code is "PEAK_073000" (peak hours), and the site belongs to a transfer station, the indexing condition is "PEAK+TRAN", which matches the exclusive basic broadcast control template "TPL_PEAK_TRAN_V3" (different from "TPL_PEAK_COM_V3" for ordinary stations). The indexing response time is ≤0.3 seconds to ensure real-time performance.

[0075] Parameter dynamic filling mapping rules:

[0076] Broadcast frequency parameter ({FREQ}): Filled according to the instantaneous value of passenger flow. When the instantaneous value is <300 people / minute, fill 4 times / minute; when it is 300-500 people / minute, fill 6 times / minute; when it is >500 people / minute, fill 8 times / minute. The filled value shall not exceed the preset threshold for this time period type (peak time threshold: 3-10 times / minute, off-peak time: 2-6 times / minute, low-peak time: 1-3 times / minute).

[0077] Voice prompt duration parameter bit ({DUR}): Linearly filled according to the train arrival delay time. 15 seconds are filled when there is no delay (0 seconds), 20 seconds are filled when the delay is 1-30 seconds, 25 seconds are filled when the delay is 31-60 seconds, and 30 seconds are filled when the delay is >60 seconds. The filling value deviation shall not exceed ±2 seconds.

[0078] Content priority parameter bit ({PRI}): Directly mapped according to the emergency event level coefficient. Coefficient 1-3 corresponds to 3 (daily priority), 4-6 corresponds to 6 (general emergency), 7-9 corresponds to 9 (higher emergency), and 10 corresponds to 10 (highest emergency). The mapping relationship strictly follows the preset emergency response rule table and has no custom adjustment permission.

[0079] The real-time data acquisition module simultaneously starts three data collection threads. The first thread extracts the instantaneous passenger flow value within the current time slice from the first cache partition. The collection logic is as follows: using the current time point as the baseline, it traces back 10 seconds to retrieve all gate passage records, sums the number of people passing through each channel, and takes the arithmetic average. For example, at 07:30:15, it acquires 1200 passage records from 07:30:05 to 07:30:15, calculating an instantaneous value of 400 people / minute. The second thread extracts train arrival delay time from the second cache partition. The calculation logic is as follows: it obtains the estimated arrival timestamp and actual arrival timestamp of the most recent train. When the actual arrival timestamp is empty, it uses the difference between the current system time and the estimated arrival timestamp. For example, if a subway train is scheduled to arrive at 07:30:00, and has not arrived by the current time of 07:30:20, the delay time is calculated as 20 seconds. The third thread extracts the emergency event level coefficient from the third cache partition. The mapping logic is as follows: query the event reports submitted within the last 5 minutes and take the value corresponding to the highest urgency level. For example, if the equipment failure event reported at 07:28 is rated as level 3 and the passenger flow abnormality event reported at 07:29 is rated as level 6, then the level coefficient 6 is taken.

[0080] The parameter filling engine uses DOM parsing technology to process the basic broadcast control template. The engine first locates the {DUR} placeholder, converting the train arrival delay of 20 seconds into a floating-point number 20.0 and filling it in. Finally, it locates the {PRI} placeholder, filling in the emergency event level coefficient of 6 as an integer. During the filling process, data type validation is performed: the broadcast frequency parameter only accepts positive integers, the voice prompt duration parameter only accepts non-negative floating-point numbers, and the content priority parameter only accepts integers within the range of 0-10. After filling, the target broadcast control template is generated, whose data structure contains three pre-assigned parameter fields and a fixed template framework. The value of the broadcast frequency parameter determines the trigger frequency of the audio broadcast device; the system calculates the broadcast interval based on this value. For example, a value of 400 translates to 4 broadcasts per minute (once every 15 seconds). The value of the voice prompt duration parameter controls the duration of a single broadcast; the system adjusts the playback rate of the audio file based on this value. For example, a value of 20.0 automatically selects a 20-second audio segment or stretches the existing audio. The value of the content priority parameter affects the sorting logic of the broadcast content. The system adjusts the output order of multiple events to be broadcast based on this value. For example, when the value is 6, the broadcast content generated by this template will be output with priority 5 or lower, but lower than content with priority 7 or higher.

[0081] The basic broadcast control templates in the broadcast control strategy library (such as "TPL_PEAK_TRAN_V3") are created through a four-stage standardized generation process to ensure the effectiveness and adaptability of the templates:

[0082] Demand Analysis Phase (Cycle: Once per quarter): Extract operational data (passenger flow fluctuations, train delay frequency, emergency event types) for the same time period and station level over the past 3 months; combine feedback from the subway operator (e.g., adding transfer guidance announcements at peak transfer stations) to clarify the core parameters that the template must include (e.g., peak transfer station templates must include parameters such as "crowding level prompts and transfer passage guidance").

[0083] Parameter definition phase: Set "type + range + default value" for each core parameter. For example, the broadcast frequency parameter is defined as a positive integer + 3-10 times / minute + 6 times / minute (default); formulate parameter association rules (such as when the emergency event level coefficient is ≥7, the fill value of the broadcast frequency parameter is forced to be increased to the upper limit of the threshold for that period).

[0084] Testing and verification phase: A pilot test was conducted at a subway transfer station in a certain city (during peak hours) for 72 hours. Feedback on the broadcast effect of the template parameters (e.g., passenger comprehension rate ≥ 85%) and equipment load rate (≤ 70%) were recorded. If the test failed (e.g., comprehension rate < 85%), the test was returned to the parameter definition phase for adjustment (e.g., increasing the duration of voice prompts) until the pass rate was ≥ 90%.

[0085] In the database update phase: Templates that pass the test are assigned a version number (e.g., V3 represents the third iteration) and stored in the corresponding index directory of the broadcast control strategy library; old version templates are archived after 6 months to ensure traceability, and template update records are synchronously uploaded to the metadata registry.

[0086] The data collection process employs an outlier filtering mechanism. When the instantaneous passenger flow exceeds 150% of the historical highest value for the same period, the system automatically activates data smoothing: calculating the weighted average of the current value and the average of the previous minute. When the calculated train arrival delay time is negative (indicating early arrival), it is automatically reset to zero. If the emergency event level coefficient fails to update in time due to network latency, the coefficient value from the previous period is used. Detailed logs are maintained for all parameter filling operations, including data source timestamps, calculation processes, and final filled values.

[0087] The template matching process supports a version rollback mechanism. When the retrieved template version is incompatible with the current system version, a slightly newer version template is automatically matched. When the time period type code does not exist in the index table, the default template "TPL_DEFAULT" is used for parameter filling. The parameter filling engine has a syntax checking function, and automatically triggers a verification alarm when a parameter value is detected to be outside the reasonable range. For example, when the instantaneous passenger flow exceeds 1000 people / minute, the system will add a special marker after the filled value for subsequent verification processing.

[0088] The real-time data acquisition module employs a multi-source data verification strategy. In addition to obtaining instantaneous passenger flow values ​​from the first cache partition, it also cross-verifies the statistical results from the video passenger flow analysis system. When the difference between the two exceeds 20%, the lower value is taken as the final result. Train arrival delay time simultaneously receives data from the train's onboard system and track sensors, taking the maximum value from multiple data sources as the final result. An emergency event level coefficient mapping table is established between event types and level values: equipment failure maps to levels 1-3, passenger flow anomalies map to levels 4-7, and safety events map to levels 8-10.

[0089] After the target broadcast control template is generated, it enters the cache queue, and each template is accompanied by a time validity identifier. The system maintains a template version management record. Each time a template is updated, the old version template is transferred to the historical database for storage, and the new version template must undergo an integrity test before it takes effect. Intermediate calculation results during the parameter filling process are retained in the memory cache for use in subsequent possible recalculation needs. When a parameter cannot be obtained due to an abnormal data source, the system uses the historical average value of the same period for filling, and marks the data source as an estimated value in the template.

[0090] The broadcast control strategy library establishes a template change tracking mechanism, recording the query conditions, matching results, and populated parameter values ​​for each template matching operation. Templates stored in the library support dynamic hot updates; when operational strategies are adjusted, the definitions and value ranges of template parameter placeholders can be directly modified through the management interface. The system periodically defragments and optimizes the template index table to ensure that matching query response times remain within milliseconds.

[0091] Example 3: See Figure 5 The logic verification module performs multi-dimensional detection on the target broadcast control template after parameter filling. The broadcast frequency parameter verification first reads the filled value of this parameter and obtains the corresponding preset frequency threshold range based on the time period type code in the time period identifier. The threshold range is set to 5-10 times per minute during peak hours, 3-5 times per minute during off-peak hours, and 1-3 times per minute during off-peak hours. The verification algorithm compares the actual filled value with the upper and lower limits of the threshold, marking it as abnormal when the value is lower than the lower limit or higher than the upper limit. For example, if the filled value is 4 times per minute during peak hours, the system generates a low frequency anomaly flag; if the filled value is 12 times per minute, a high frequency anomaly flag is generated.

[0092] The verification of the voice prompt duration parameter is performed using spatial matching degree calculation. The system extracts real-time train location data from the second cache partition, including the precise distance between the train and the platform and its operating speed. The theoretical broadcast duration is calculated using the following formula:

[0093] ,

[0094] in: The theoretical speech duration (in seconds) is shown. This indicates the remaining distance (in meters) between the train's current position and the platform. This indicates the train's current average speed (meters per second). This indicates the basic broadcast buffer duration (fixed at 3 seconds). The calculated theoretical duration is compared with the actual filled voice prompt duration parameter value. If the deviation exceeds ±5 seconds, it is judged as an abnormal spatial matching degree.

[0095] Content priority parameter verification is based on preset emergency response rules. These rules stipulate that: Level 1 emergency events (fire, earthquake, etc.) must correspond to priority 10; Level 2 emergency events (serious equipment failure, large passenger flow congestion) correspond to priorities 7-9; Level 3 emergency events (general equipment failure, minor passenger flow abnormalities) correspond to priorities 4-6; and routine events correspond to priorities 1-3. The verification process queries the event type field of the emergency event reporting data to check if its mapping relationship with the filled priority value conforms to the rules. For example, when the event type is "fire," if the filled priority value is lower than 10, an abnormal level mapping flag is generated. After each broadcast control command is executed, the system records three sets of execution result data. Command response delay is measured using a high-precision timer, recording the time difference from the moment the broadcast control command is generated to the moment the audio equipment actually outputs, in milliseconds. Passenger dwell time variation is calculated by analyzing gate data, comparing the change in average passenger dwell time within 5 minutes before and after the broadcast. Equipment energy consumption increment is read from the power management system, recording the additional power consumption of the broadcast control equipment during execution, in watt-hours.

[0096] Execution result data is bound to time period identifiers and then stored in the strategy optimization library. The library structure adopts a time series database design, with each record containing a timestamp, a time period identifier, and three types of execution result data values. Data storage is partitioned according to time period type: peak period data is stored in the peak partition, off-peak period data is stored in the normal partition, and low-peak period data is stored in the low partition.

[0097] The strategy optimization library is updated using a periodic batch processing method. Every 24 hours, historical execution result data sequences for the same time period identifier are extracted, and three indicators are calculated: the volatility of command response delay, the trend coefficient of passenger dwell time variation, and the load gradient of equipment energy consumption increment. The volatility of command response delay is calculated as the ratio of standard deviation to mean, reflecting the stability of command execution. The trend coefficient of passenger dwell time variation is obtained through linear regression analysis; a positive coefficient indicates an increase in dwell time, and a negative coefficient indicates a decrease. The load gradient of equipment energy consumption increment is calculated as the average of energy consumption differences between adjacent time points, reflecting the rate of energy consumption change. When the volatility exceeds the preset stability threshold of 0.25, the system automatically adjusts the baseline value of the voice prompt duration parameter corresponding to that time period identifier. The adjustment range is determined based on the volatility: when the volatility is between 0.25 and 0.5, the baseline value is reduced by 5%; when the volatility exceeds 0.5, the baseline value is reduced by 10%. The adjusted new baseline value is immediately updated in the parameter threshold mapping table of the broadcast control strategy library. When the trend coefficient shows a continuous negative shift (three consecutive negative values), the upper limit of the broadcast frequency parameter corresponding to the time period identifier should be recalibrated. The calibration method is to take 90% of the current upper limit as the new upper limit, but it must not be lower than the minimum frequency requirement for that time period type. For example, if the original upper limit for peak hours was 10 times per minute, it would become 9 times per minute after calibration.

[0098] Based on the screen refresh rate parameters of the display terminal update command dynamically compressed according to the load gradient, the load gradient is divided into three levels: when the gradient value is below 5, the original refresh rate is maintained; when the gradient value is between 5 and 10, the refresh rate is reduced to 75% of the original value; when the gradient value exceeds 10, the refresh rate is reduced to 50% of the original value. Refresh rate adjustment only applies to non-emergency broadcast content; the refresh rate of emergency broadcasts remains unchanged. Anomalies generated during the verification process are stored in an anomaly knowledge base. The base records the anomaly type, occurrence time, associated parameter bits, and final handling method. These records are used to optimize verification rules; for example, when a certain anomaly occurs frequently, the system will automatically adjust relevant thresholds or matching rules. A version control mechanism is established in the strategy optimization base; a new version record is generated each time the parameter threshold is updated, while the old version configuration is retained for rollback.

[0099] The data acquisition module employs a multi-verification mechanism when recording execution results. Command response delay data is collected simultaneously from both the broadcast control equipment controller and the audio output device, with the larger value being the final recorded value. When calculating changes in passenger dwell time, extreme values ​​are excluded; the longest and shortest 10% of dwell time records are removed before calculating the average. Energy consumption increments are recorded separately for different equipment types, with screen devices and audio devices recording their respective energy consumption data. A tiered response mechanism is established for anomaly handling. Level 1 anomalies (such as priority mapping errors) immediately trigger the broadcast control decision refactoring process; Level 2 anomalies (such as minor frequency exceedances) are recorded but execution continues; Level 3 anomalies (such as minor spatial matching deviations) are only logged without interrupting the process. All anomaly handling records are synchronized in real-time to the dispatch center monitoring interface for operational staff supervision.

[0100] The strategy optimization library update operation is equipped with a security protection mechanism. The adjustment range of parameter thresholds is limited to a maximum of 20% of the original value in a single adjustment. Simulation tests are conducted before each adjustment, and historical data is used to verify the effectiveness of the new thresholds. A whitelist mechanism is established, requiring manual confirmation before parameter thresholds for critical periods take effect.

[0101] Example 4: See Figure 4 When the logic verification module detects an anomaly in the voice prompt duration parameter, it extracts the padding value "35 seconds" and its data source "Train Positioning Unit G12". The system generates an anomaly type identifier "203", where the first "2" represents a voice duration anomaly and the last "3" represents the data source number. This identifier is input into the decision reconstruction network, where it matches the associated decision node "Node_DUR_G12" in the network topology. The adjustment coefficient mapping table stored in the node contains three sets of parameters: aggressive adjustment (remaining duration < 5 minutes), standard adjustment (5-15 minutes), and conservative adjustment (> 15 minutes). With 8 minutes remaining in the current time slice, a standard adjustment coefficient of 0.7 is selected. Using the formula: Correction value = Original value × (1 + Adjustment coefficient), 35 × (1 + 0.7) = 25.5 seconds is calculated and used to replace the original padding value. Actual testing shows that this correction improves the clarity of the delay announcement by approximately 40%.

[0102] The executable broadcast control instruction set generation process parses and reconstructs the target broadcast control template. The audio output instruction configures the sound pressure level adjustment parameter to 85 dB, which is calculated based on a station hall area of ​​2000 square meters and a background noise of 70 dB. The display terminal update instruction sets the multi-screen synchronization delay parameter to 150 milliseconds, covering the refresh sequence of the eight screens on the platform. The emergency broadcast channel selection instruction configures the priority coverage flag bit "1" to forcibly interrupt the current daily broadcast. Test records show that this configuration controls the multi-screen information synchronization error within 50 milliseconds and accelerates the emergency broadcast response speed to 1.2 seconds. The mapping relationship between the anomaly type identifier and the decision node is shown in Table 1.

[0103] Table 1: Mapping Table of Exception Type Identifiers and Decision Nodes

[0104]

[0105] For example, if the identifier "305" triggers the node "Node_PRI_5", and the emergency event level coefficient is mistakenly entered as 3 (it should actually be 8), the remaining 12 minutes will use a conservative coefficient of 0.4. The correction value = 3 × (1 + 0.4) = 4.2, which is rounded to 4. On-site verification shows that this adjustment improves the accuracy of event broadcast priority to 92%.

[0106] The voice content in the audio output command is generated through a combination of TTS synthesis and pre-set segment splicing. The basic configuration of the voice library includes a pre-set subway-specific voice library containing three versions: Chinese (Mandarin), English, and the local dialect of the subway. The library has a sampling rate of 44.1kHz, a bit depth of 16bit, and a signal-to-noise ratio ≥80dB, covering 12 core scenario scenarios such as time-of-day prompts, transfer guidance, and emergency evacuation. The voice library is updated quarterly, adding station names and policy adjustment prompts (such as security check upgrade prompts). Dynamic voice synthesis is based on a target broadcast control template with parameter filling. The system parses fixed speech segments + dynamic parameter values. For example, when the template parameters are {FREQ}=6 times / minute and {DUR}=20 seconds, the parsing result is a fixed segment: "Currently it is peak time, broadcast frequency is" + dynamic value: 6 times / minute + fixed segment: "Voice prompt duration is" + dynamic value: 20 seconds; The system calls a TTS engine (using iFlytek IFlyTTS). Version 4.0 synthesizes dynamic parameter values ​​(e.g., 6 times / minute) into speech segments. The speech rate of the synthesized speech is fixed at 120 words / minute, with a neutral and stable tone to avoid passenger auditory fatigue. For speech splicing and quality control, preset fixed segments and TTS synthesized segments are logically spliced ​​together to form complete speech (e.g., during peak hours, the broadcast frequency is 6 times / minute, and the voice prompt duration is 20 seconds; please pay attention to train arrival information). After splicing, the speech must pass a noise environment intelligibility test: under a background noise level of 75 dB in the station hall (peak hour threshold), the speech intelligibility index is tested using acoustic equipment to be ≥0.6. If it does not meet the standard, the speech sound pressure level is automatically increased by 0.5 dB, and the test is repeated until it meets the standard. For speech output adaptation, the speech format is adjusted according to different broadcast control equipment (station hall broadcasts, carriage broadcasts, platform display screens). For example, the station hall broadcast output is in MP3 format with a bitrate of 192kbps, and the carriage broadcast output is in WAV format with a bitrate of 128kbps to ensure equipment compatibility.

[0107] When the audio output command is generated, the sound pressure level adjustment parameter is dynamically calibrated. When a sudden increase in noise to 78 dB is detected on the east side of the station hall, the system automatically increases the sound pressure level from 85 dB to 88 dB. Test data records show that this adjustment increases the speech intelligibility index from 0.65 to 0.82. During the execution of the display terminal update command, the screen refresh rate drops from 60Hz to 45Hz, and the device temperature decreases by approximately 5℃. After setting the multi-screen synchronization delay parameter, the system records the actual refresh time difference between each screen: screen 1 and screen 2 differ by 42 milliseconds, and screen 3 and screen 4 differ by 37 milliseconds, both within the allowable deviation range.

[0108] When the priority overlay flag of the emergency broadcast channel selection command is set to "1", the system immediately releases the currently playing music announcement and switches to the emergency broadcast channel. The broadcast execution logic based on the temporary emergency time period code "PEAK_073000_EMG" is as follows: Broadcast frequency: exceeding the frequency threshold of the original time period type, fixed at once every 30 seconds until the event is resolved; Content priority: Emergency broadcast content forcibly overwrites all regular content, even if the regular content has a priority of 9, it is still lower than the emergency content's priority of 7; Multi-channel synchronization: The temporary emergency time period code is synchronously pushed to audio equipment, display terminals, and the emergency broadcast channel to ensure consistent information in the station hall, platform, and carriages, with a synchronization error ≤ 50 milliseconds. Actual testing shows that the channel switching time has been reduced from the usual 2.1 seconds to 0.9 seconds. When multiple emergency events are triggered simultaneously, the system executes them according to priority flags: events with priority 10 are forcibly inserted into the broadcast, events with priorities 7-9 are queued and wait for the current broadcast to end, and events with priorities 4-6 are delayed for 60 seconds.

[0109] A rollback mechanism is established during the decision reconstruction process. When a correction value triggers a secondary anomaly, the system automatically reverts to the initial fill value and activates a backup decision node. For example, if a voice duration correction value of 25.5 seconds triggers a spatial matching anomaly, the system rolls back to the original value of 35 seconds and switches to node "Node_DUR_3B" for recalculation. Records show that this mechanism reduces the system error rate by approximately 35%. A dual-check protocol is used for instruction set transmission. Audio output instructions are appended with a CRC checksum, and display terminal instructions have a parity check bit added. When a transmission error is detected, the system automatically retransmits the three most recent instructions. Statistics show that this mechanism maintains an instruction transmission success rate of over 99.97%. All generated instruction sets are timestamped and version-marked and stored in the operation log, supporting post-event traceability and analysis. During the evening rush hour stress test, the system successfully handled three consecutive abnormal events: First, an abnormal instantaneous passenger flow value triggered identifier "101," and the frequency parameter was corrected using an aggressive coefficient of 0.6; then, a train positioning failure triggered identifier "212," and the voice duration was adjusted using a coefficient of 0.8; finally, a sudden large passenger flow event generated identifier "305," and the priority was corrected using a coefficient of 0.5. Records show that the entire reconstruction process took 1.8 seconds, and the generated instruction set improved platform passenger evacuation efficiency by approximately 25%. Equipment operation logs indicate that the dynamically adjusted broadcast control scheme reduced audio equipment power consumption by 18% and extended screen equipment lifespan by approximately 1200 hours.

[0110] Example 5: During the execution of the audio output command, a microphone array distributed throughout the station hall collects ambient noise at a sampling frequency of 10 times per second. The array consists of 32 high-sensitivity condenser microphones, arranged in an 8×4 grid to cover the entire station hall area. Each microphone has a built-in pre-emphasis filter to effectively capture human voice energy in the 80Hz to 8kHz frequency band. The collected raw sound pressure signals are converted into a decibel value sequence after A / D conversion and transmitted to the central processing unit for weighted average calculation. During the calculation, the highest and lowest 5% extreme values ​​are removed, and the arithmetic mean of the remaining data is taken as the current noise decibel value. This value is updated every 0.1 seconds and stored in a circular buffer, which retains the historical data of the most recent 60 seconds.

[0111] The noise tolerance threshold is dynamically set based on the time period identifier code. The system parses the time period type encoding field in the time period identifier code: "PEAK" corresponds to a 75 dB threshold, "NORM" corresponds to a 70 dB threshold, and "LOW" corresponds to a 65 dB threshold. The threshold setting is based on the acoustic characteristics of the station hall building, considering a sound field environment with a reverberation time of 1.8 seconds. When the real-time noise decibel value exceeds the current threshold, the system calculates the noise exceedance. For example, during peak hours (threshold 75 dB), when the measured noise is 78 dB, the exceedance is 3 dB. The output gain is automatically increased according to the exceedance ratio: for every 1 dB increase in exceedance, the sound pressure level adjustment parameter increases by 1 dB gain. In the example above, with an exceedance of 3 dB, the system increases the current output gain from 85 dB to 88 dB.

[0112] The gain boost process employs a stepped adjustment mechanism, with each gain adjustment set in a minimum unit of 0.5 dB and an adjustment interval of at least 5 seconds. When the noise decibel value continuously exceeds the limit, the system detects the change in the excess every 5 seconds and recalculates the gain value based on the latest excess. The upper limit of gain boost is set to 15 dB above the threshold to prevent excessive amplification and audio distortion. All gain adjustment operations are logged in detail, including adjustment time, original gain value, new gain value, and trigger noise value. When the noise decibel value continuously falls below the threshold, the system initiates a gain attenuation process. The preset duration is set to trigger the condition of being below the threshold for 30 consecutive seconds, and the timer starts accumulating from the first time it falls below the threshold. After the 30-second condition is met, the system reduces the gain value by 1 dB every 10 seconds. For example, during off-peak hours (threshold 70 dB), when the noise remains stable at 68 dB for 35 seconds, the system first reduces the gain at the 30-second mark and then reduces the gain again at the 40-second mark. The attenuation process is protected by a lower limit, and the gain value must not be lower than the reference sound pressure level corresponding to the time period type: 80 dB for peak time, 75 dB for off-peak time, and 70 dB for trough time.

[0113] The reference sound pressure level initialization is completed when the audio output command is generated. The system loads a preset reference value according to the time period identifier code and performs calibration in conjunction with the station hall volume parameters: the standard reference value is used for spaces below 2000 cubic meters, 3 dB is added for spaces between 2000 and 5000 cubic meters, and 5 dB is added for spaces above 5000 cubic meters. The calibrated reference value serves as the original starting point for gain adjustment, and all gain adjustments are based on this.

[0114] The closed-loop feedback mechanism runs the linkage control of noise monitoring and gain adjustment in real time. The system establishes a dual-loop control structure: the inner loop compares the relationship between the latest noise value and the threshold every 0.1 seconds; the outer loop makes a gain adjustment decision every 5 seconds. The two loops share a noise data buffer but use independent decision-making algorithms. When the inner loop detects that the noise mutation exceeds 10 decibels, it immediately triggers an interruption of the outer loop and starts an emergency gain adjustment process. A hysteresis interval is set in the control process. When the noise is within the range of ±2 decibels of the threshold, no adjustment is triggered to prevent audio fluctuations caused by frequent fine-tuning.

[0115] The microphone array implements a cross-check mechanism. The system divides the station hall into four areas, with 8 microphones in each area. When the noise detection value in a certain area differs from that in other areas by more than 15%, the sensor diagnosis program is started: a test sound source signal is sent to this area to check the microphone response curve. When a faulty sensor is found, its data is automatically excluded, and data interpolation compensation of the adjacent area is used. All microphones perform automatic calibration every 24 hours, and a standard 94 dB sound pressure source is used for sensitivity correction.

[0116] The differential coding is used for the transmission of gain adjustment instructions. Each time the gain changes, only the incremental value rather than the absolute value is transmitted, reducing the amount of data transmission. After receiving the incremental instruction, the audio controller adjusts the gain of the power amplifier circuit through a digital potentiometer. A 50-millisecond gradual transition is set during the adjustment process to avoid auditory discomfort caused by sudden changes in sound pressure. The system records the audio spectrum characteristics before and after each gain adjustment to ensure that the speech intelligibility index remains above 0.6. In the processing of the transition period, the system adopts a dual-threshold strategy. For example, during the transition period from 07:10 to 07:15, the low valley period and the peak period identification codes are associated at the same time. The noise threshold in this period takes the weighted average of the two periods: at the start of the period, the low valley threshold weight is 80%, and it linearly decreases to 20% at the end of the period as time goes by. The gain reference value is also dynamically mixed according to this weight to achieve a smooth transition during the period switch. The abnormal noise processing module monitors sudden high-decibel noises. When it detects that the instantaneous noise exceeds 100 decibels and lasts for more than 0.5 seconds, it is determined as an abnormal impact noise (such as an object falling or equipment abnormal sound). The system immediately pauses the gain adjustment process, maintains the current gain setting for 10 seconds, and resumes the control loop after the noise event ends. All abnormal noise events record the time, location, and spectrum characteristics for optimizing the noise recognition algorithm.

[0117] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0118] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A metro information broadcasting method based on time period scheduling, characterized in that, Comprise: Step 1: real-time acquisition of subway operating environment of multi-source monitoring data, the multi-source monitoring data includes passenger flow data, train arrival data and emergency event reporting data; Step 2: based on the preset time period division rule, the current operation cycle is divided into a plurality of continuous time slices, and the corresponding time period identification code is generated for each time slice; Step 3: according to the time period identification code, the target broadcast control template is matched from the broadcast control strategy library, and the target broadcast control template is dynamically filled with parameters based on the multi-source monitoring data; Step 4: the target broadcast control template after parameter filling is logically verified, and when the verification is abnormal, the broadcast control decision reconstruction process is triggered, and when the verification is normal, the executable broadcast control instruction set is generated.

2. The time period scheduling based subway information broadcasting method according to claim 1, wherein, The step 1 in real-time acquisition of subway operating environment of multi-source monitoring data, comprising: Synchronously collect passenger flow data, train arrival data and emergency event reporting data through gate counting unit, train positioning unit and dispatching station event recording unit respectively; Establish independent data cache partition for each type of data, store the passenger flow data into the first cache partition, the train arrival data into the second cache partition, and the emergency event reporting data into the third cache partition in time stamp order; When any data cache partition reaches the preset data volume threshold, upload the data in the partition to the central data pool according to the time frame sequence.

3. The time period scheduling based subway information broadcasting method according to claim 2, wherein, The step 2 in the time slice based on the preset time period division rule, comprising: Extract the historical same period passenger flow fluctuation curve from the central data pool, identify the demarcation time point of the flow peak period, the flat peak period and the trough period; Cut the current operation cycle with the demarcation time point as the node, generate a time period sequence containing at least peak period slice, flat peak period slice and trough period slice; Assign a unique time period identification code to each time period slice, which contains time period type code and starting time stamp.

4. The time period scheduling based subway information broadcasting method according to claim 3, characterized in that, The step 3 in matching target broadcast control template and filling parameters, comprising: Match the time period type code in the time period identification code with the template index of the broadcast control strategy library, output the basic broadcast control template; Real-time acquisition of passenger flow instantaneous value, train arrival delay time, emergency event level coefficient in the current time slice; Fill the passenger flow instantaneous value into the broadcast frequency parameter bit of the basic broadcast control template, fill the train arrival delay time into the voice prompt time parameter bit, and fill the emergency event level coefficient into the content priority parameter bit.

5. The time period scheduling based subway information broadcasting method according to claim 4, wherein, The step 4 in the logic verification of the target broadcast control template after parameter filling, comprising: Detect whether the broadcast frequency parameter bit exceeds the preset frequency threshold range corresponding to the time period type code; Compare the spatial matching degree of the voice prompt time parameter bit and the real-time position data of the train; Verify whether the level mapping relationship between the content priority parameter bit and the emergency event reporting data meets the preset emergency response rule.

6. The time period scheduling based subway information broadcasting method according to claim 5, wherein, When the verification is abnormal, trigger the broadcast control decision reconstruction process, execute: Extract the parameter bit and its associated data source of the verification exception, generate an exception type identifier; According to the exception type identifier, match the associated decision node in the decision reconstruction network, and select the dynamic adjustment coefficient in the associated decision node based on the remaining time length of the current time slice; The abnormal parameter bit is recalculated by using the dynamic adjustment coefficient to replace the original filling value.

7. The time period scheduling based subway information broadcasting method according to claim 6, wherein, When generating the executable broadcast control instruction set, the following steps are included: The target broadcast control template after filling the parameters is parsed to separate the audio output instruction, the display terminal update instruction, and the emergency broadcast channel selection instruction. The sound pressure level adjustment parameter is configured for the audio output instruction, the multi-screen synchronization delay parameter is configured for the display terminal update instruction, and the priority override flag bit is configured for the emergency broadcast channel selection instruction.

8. The time period scheduling based subway information broadcasting method according to claim 7, wherein, Further included are: During the execution of the audio output instruction, the station hall noise decibel value is collected in real time; When the noise decibel value exceeds the noise tolerance threshold corresponding to the current time period type code, the output gain value of the sound pressure level adjustment parameter is automatically increased according to the difference ratio; When the noise decibel value continuously falls below the noise tolerance threshold for a preset length of time, the output gain value is gradually reduced.

9. The time period scheduling based subway information broadcasting method according to claim 1, wherein, After step 4, further included are: The execution result data of each broadcast control instruction is recorded, and the execution result data includes the instruction response delay, the passenger stay time length change amount, and the device energy consumption increment; The execution result data is bound to the corresponding time period identification code and stored in the strategy optimization library for updating the parameter threshold mapping relationship in the broadcast control strategy library.

10. The time period scheduling based subway information broadcasting method according to claim 9, wherein, The updating process of the strategy optimization library includes: The historical execution result data sequence of the same time period identification code is extracted to calculate the fluctuation rate of the instruction response delay, the trend coefficient of the passenger stay time length change amount, and the load gradient of the device energy consumption increment; When the fluctuation rate exceeds the preset stability threshold, the reference value of the voice prompt time length parameter bit corresponding to the time period identification code is adjusted; When the trend coefficient shows a continuous negative deviation, the upper limit value of the broadcast frequency parameter bit corresponding to the time period identification code is recalibrated; According to the load gradient, the screen refresh rate parameter of the display terminal update instruction is dynamically compressed.

Images