AFC system station management method and device and electronic equipment

Abstract

The invention relates to the technical field of rail transit automatic fare collection systems, and discloses an AFC system station management method which comprises the following steps: equipment state data acquisition: operating state data of various equipment in an AFC system are acquired through an embedded sensor, and the operating state data comprise online states, transaction records and fault information of the equipment; data transmission and storage: uploading the collected operation state data to a central control system through an optimized data transmission protocol, and storing the data in a database; and equipment state monitoring and fault alarm: based on the operation state data, monitoring the operation state of the equipment, and if the equipment is detected to be abnormal, triggering alarm. Through the data acquisition module and the state monitoring module, real-time monitoring of operation states of various devices in the AFC system is realized, and an alarm signal is automatically triggered based on a fault probability model, so that fault discovery and response time is remarkably shortened.

Description

Technical Field

[0001] The present invention relates to the technical field of automatic fare collection systems for rail transit, and specifically to an AFC system station management method, device, and electronic device. Background Art

[0002] In recent years, with the rapid development of urban rail transit, the automatic fare collection system (AFC) has become a core component of urban rail transit systems such as subways and light rails. With its high efficiency and intelligent features, the AFC system can realize functions such as ticket management, equipment monitoring, and passenger flow analysis, and has an indispensable position in modern traffic operations. However, with the continuous expansion of the scale of the traffic network and the increase in equipment complexity, there are still some technical bottlenecks in the existing AFC system for station management.

[0003] The existing station management mode of the AFC system usually focuses on decentralized management and lacks a unified integrated platform. Data between subsystems cannot be shared and linked in real time, which leads to the following main problems: Currently, most AFC systems mainly rely on manual regular inspections of equipment or a single equipment monitoring interface, making it difficult to achieve real-time status monitoring of all station equipment. Once a device fails, the process of discovering, locating, and handling the failure takes a long time, which may affect the passenger passage efficiency. In addition, the traditional system lacks the ability to intelligently analyze and predict the operating status of equipment and cannot timely warn of potential failure risks. The existing system mainly relies on manual operations during the operation mode switching of the station and is difficult to respond in a timely manner to changes in passenger flow fluctuations. For example, during peak hours or special events, the on / off status of equipment and resource allocation cannot be automatically adjusted, resulting in idle equipment resources or insufficient service capabilities in some cases, seriously affecting the operation efficiency of the system. Summary of the Invention

[0004] In view of the deficiencies of the prior art, the present invention provides an AFC system station management method, device, and electronic device, which solve the problems of low equipment monitoring efficiency, inflexible operation mode, insufficient data processing quality, and weak authority management and data analysis functions in the existing AFC system.

[0005] To achieve the above objectives, the present invention is realized through the following technical solutions: An AFC system station management method, including the following steps: Device status data collection: Collect the operating status data of various devices in the AFC system through embedded sensors, where the operating status data includes the online status, transaction records, and fault information of the devices; Data transmission and storage: Upload the collected operating status data to the central control system through an optimized data transmission protocol and store it in a database; Device status monitoring and fault alarm: Based on the operation status data, monitor the operation status of the device. If device anomalies are detected, trigger an alarm. Mode management: Adjust the operation mode of the station according to operation requirements, including peak mode, off-peak mode, or specific event mode. Data cleaning and analysis: Clean the stored operation status data, remove duplicate or abnormal data, and analyze the cleaned data to predict passenger flow or device usage requirements. Permission management and log recording: Allocate permissions for system functions based on user roles and record the operation logs of users; Revenue and ticketing management: Record the station revenue and ticketing information. Report generation and data export: Generate operation reports based on the cleaned data and export the data in the form of electronic files.

[0006] Preferably, the device status monitoring includes the following steps: Based on historical operation status data, calculate the probability of device failure through a prediction model. If the failure probability exceeds a preset threshold, trigger an alarm signal. After a fault alarm, provide the operator with the location information and fault type of the faulty device.

[0007] Preferably, the mode management includes the following steps: After the operator enters a password to verify their identity, send a mode switching instruction through the system. The mode switching instruction includes control instructions for batch adjustment of the operation status of various devices. The control instructions involve suspending service, normal operation, or switching to a two-way mode of the devices.

[0008] Preferably, the data cleaning includes the following steps: Perform rule verification on the timestamps, amounts, and data formats in the transaction records, and remove transaction records that do not conform to the rules. Based on the cleaned data, predict the passenger flow and dynamically adjust the number of devices turned on in combination with historical passenger flow and external factors.

[0009] Preferably, the permission management includes the following steps: Configure a permission set according to the user role. The permission set defines the functional modules that the user can operate. The user permissions are dynamically loaded by the central system and displayed in the form of a function menu on the system main interface. The operation log records the operator number, operation time, operation type, and specific operation content of the user.

[0010] Preferably, the revenue and ticketing management includes: Record the use and surrender information of tickets according to the actual operational needs of the station; The inventory quantity of station tickets is dynamically updated. The inventory quantity of tickets is the initial inventory minus the number of tickets already issued plus the number of returned tickets.

[0011] The present invention provides an AFC system station management method, device and electronic equipment, which have the following beneficial effects: 1. The present invention realizes real-time monitoring of the operating status of various types of equipment in the AFC system through the data acquisition module and the status monitoring module, and automatically triggers the alarm signal based on the fault probability model, thereby significantly shortening the fault discovery and response time. At the same time, the system can provide accurate fault location and analysis results, assist maintenance personnel to efficiently complete fault troubleshooting and maintenance, and improve the overall availability and operating efficiency of the equipment.

[0012] 2. The mode management module provided by the present invention can dynamically adjust the operating status of the equipment according to the station operation requirements, such as full equipment on mode during peak hours or partial equipment sleep mode during off-peak hours. Through the analysis and prediction of passenger flow data, the system can reasonably allocate equipment resources when switching operating modes, thereby reducing energy and labor costs while ensuring service quality, and optimizing the overall operating efficiency of the station.

[0013] 3. The present invention uses a data cleaning module to perform rule verification and anomaly elimination on the collected operating status data, thereby ensuring the accuracy and integrity of the system data. The cleaned high-quality data can not only avoid decision-making deviations caused by erroneous data, but also provide a reliable data basis for subsequent revenue statistics, passenger flow analysis and report generation, thereby supporting station managers to make accurate decisions.

[0014] 4. The authority management module of the present invention adopts the role-based authority control (RBAC) mechanism to dynamically allocate functional authority according to user roles, record all operation behaviors and generate operation logs. Through strict authority restrictions and operation traceability design, the system effectively prevents unauthorized operations and potential security risks, and further ensures the controllability and security of station management. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a flow chart of the method of the present invention; Figure 2 It is a schematic diagram of the device of the present invention. DETAILED DESCRIPTION

[0016] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0017] Embodiment: Please refer to the attached Figure 1 - attached Figure 2 , the embodiment of the present invention provides an AFC system station management method, including the following steps: S1. Collection of device status data: Collect the operation status data of various devices in the AFC system through embedded sensors. The operation status data includes the online status of the device, transaction records, and fault information. In view of the problem of collecting device operation status data in the AFC system station management, the present invention proposes an efficient data collection method. As the core basic step of the AFC system station management method, data collection is directly related to the realization of subsequent functions such as device status monitoring, fault alarm, mode management, and data analysis. Therefore, through the embedded sensors, the device status data is comprehensively collected, and through the optimized data transmission protocol and formatting process, the integrity and accuracy of the data are ensured, providing a strong guarantee for the stable operation of the system.

[0018] In this embodiment, the device status data collection method specifically includes the following content: As an option, the status of various devices in the AFC system is monitored through embedded sensors. The devices include TVM (self-service ticket vending machine), AGM (gate for entering and leaving the station), and BOM (manual ticket vending machine). The embedded sensors are installed in the key modules of the devices, such as the communication interface, power supply module, and operation panel, to monitor the device operation status in real time.

[0019] Specifically, the collection content of the device operation status data includes the following categories: Online status data, used to judge the connection and operation of the device; Transaction record data, used to analyze the usage frequency and transaction success rate of the device; Fault information data, used to identify potential or existing fault problems of the device.

[0020] It should be noted that the online status data is monitored through the device heartbeat packet signal. Exemplarily, the device sends heartbeat packets to the central system at fixed time intervals (such as 1 second or 5 seconds). Each heartbeat packet includes information such as the device ID, timestamp, and current status code. When multiple consecutive heartbeat packets are not received, the system marks the device as "offline" and generates an offline warning record.

[0021] In some embodiments, the collection of transaction record data is mainly carried out through the transaction module of the device. Taking the TVM as an example: The data of each transaction record includes: transaction amount, ticket type, payment method, transaction time, operation status, etc.

[0022] For example, when a user completes an e-payment ticket purchase on a TVM device, the format of the transaction record can be: D transaction = {ID, amount, ticket type, time, status} Wherein, ID is the unique identifier of the ticket, amount is the ticket purchase amount, and status indicates whether the transaction is successful.

[0023] In another possible implementation, the data collection of the AGM device includes the transaction data recorded when a user swipes the card to enter or exit the station. Specifically, the recorded transaction data includes the physical ID, logical ID, entry and exit time, turnstile number, etc. of the ticket, which are used for subsequent passenger flow analysis and data verification.

[0024] It should be noted that the collection of fault information data depends on the self-diagnosis function of the device. For example, when the device has a communication interruption, a power failure, or a hardware module is damaged, the device will generate a specific fault code and upload it to the system through an embedded sensor. The fault code is usually represented in a standard format. For example, "E1001" represents a communication fault, and "E2002" represents a hardware module fault, etc.

[0025] As a possible extension method, the fault information also includes the detailed operation data of the device module. For example, the TVM device can collect information such as the working temperature of its printer module, the remaining capacity of the ticket box, and the currency quantity of the banknote change device. These information are embedded in the fault report in the form of additional fields for maintenance personnel to conduct detailed diagnosis.

[0026] In an exemplary implementation, in order to improve the accuracy and integrity of data collection, the present invention further performs formatting processing on the collected data. Specifically, the collected data will be stored in a unified structured format, such as JSON or XML format. For example: D 采集 = {device ID, heartbeat timestamp, transaction data, fault information} This formatted data structure facilitates subsequent data transmission, storage, and analysis.

[0027] It should be understood that the formatting processing not only standardizes the storage form of the data, but also provides convenience for subsequent data cleaning and analysis. For example, for the collected redundant or redundant information, it can be marked as invalid data during the formatting process so as to be filtered out in subsequent processing.

[0028] It should be further noted that the above-mentioned method for collecting device status data is not only applicable to common devices in the AFC system, but can also be extended to other types of intelligent transportation devices, such as automatic security inspection machines, self-service terminals, etc., to meet the more extensive system management requirements.

[0029] S2. Data transmission and storage: Upload the collected operation status data to the central control system through an optimized data transmission protocol and store it in the database. In the AFC system station management method, the transmission and storage of device operation status data are important links in the entire system data processing chain. Its main task is to transmit the operation status data collected in step S1 to the central control system through the network and store it in the database, providing basic support for subsequent data analysis, device status monitoring, report generation and other functions. In order to achieve efficient, stable and secure data transmission and storage, the present invention adopts an optimized data transmission protocol, data compression technology and distributed storage architecture, and uniformly formats the data.

[0030] In this embodiment, the data transmission and storage method specifically includes the following content: As an option, the data transmission uses the TCP / IP protocol, which is applicable to the data upload of distributed devices within the station network. Specifically, the device operation status data is first collected by the embedded sensor and encapsulated into data packets by the device local communication module. The data packet structure includes device identification (device ID), data type, timestamp, operation status and specific content.

[0031] Exemplarily, the structured content of the data packet can be expressed as: Data_Packet = {device ID, data type, timestamp, operation status, content} Where: The device ID uniquely identifies the data source. The data type is used to distinguish online status data, transaction record data and fault information data. The timestamp is used to record the time point when the data is generated to ensure the chronological integrity of the data. The operation status is the current status code or fault code of the device. The content is the detailed information corresponding to the data type.

[0032] It should be noted that the data packet uses encrypted transmission when uploading to ensure data security. As an implementation method, AES (Advanced Encryption Standard) is used to perform symmetric encryption on the data. The encryption process is as follows: The plaintext data D generates the ciphertext data C through the AES encryption algorithm: C = E k (D) Among them, k is the key, and the key is dynamically updated through a pre-configured key management system.

[0033] After receiving the encrypted data, the server decrypts it with the same key to obtain the original data D': D' = D k (C) It can be understood that this data transmission method based on symmetric encryption not only ensures the data confidentiality during the transmission process but also has high encryption and decryption efficiency, and is suitable for the data upload scenario of large-scale AFC devices.

[0034] As an extended method, the present invention also introduces an incremental update mechanism to optimize the data transmission efficiency. Specifically: For online status data, only upload new status information when the device status changes. For example, if the heartbeat status of the device changes from "normal" to "offline", the system will upload new heartbeat packet data.

[0035] For transaction record data, the device can adopt a batch upload method, such as uploading the collected transaction records once every 10 minutes.

[0036] It should be noted that the incremental update mechanism can significantly reduce data redundancy and improve the transmission efficiency, especially effective in the case of a large number of devices.

[0037] In a possible implementation manner, to ensure the high reliability of the data, the present invention introduces a data backup mechanism during the storage process. Specifically: When the data is stored in the main database, backup data is generated and stored in a remote backup server.

[0038] Incremental backup files are generated daily to ensure that the data can be restored in case of an accident.

[0039] It can be understood that this data backup mechanism can effectively improve the disaster tolerance ability of the system and ensure the security and integrity of the station data.

[0040] S3. Device status monitoring and fault alarm: Based on the operating status data, monitor the operating status of the device. If a device anomaly is detected, trigger an alarm; In the AFC system station management method of the present invention, equipment status monitoring and fault alarm are one of the core links. Its function is to monitor the operation of various equipment in the station in real time based on equipment operation status data, promptly identify possible abnormal conditions, and trigger the alarm mechanism. Through this step, the system downtime caused by equipment failures can be effectively reduced, and accurate fault location and diagnosis information can be provided to maintenance personnel, thus ensuring the efficient operation of the entire AFC system.

[0041] In this embodiment, the equipment status monitoring and fault alarm specifically include the following: As an option, the implementation of equipment status monitoring is based on the classification processing of equipment operation status data. Specifically, the system adopts different monitoring strategies according to the data types uploaded by the equipment (such as online status data, transaction record data, and fault information data): For online status data, the online status of the equipment is judged by analyzing the receiving frequency of the equipment heartbeat packet. Exemplarily, when the equipment does not send a heartbeat packet for two consecutive heartbeat cycles, the system marks it as the "offline" state.

[0042] For transaction record data, the transaction performance of the equipment is analyzed by counting the transaction success rate of the equipment. For example, within a statistical period, if the transaction success rate is lower than a set threshold (such as 90%), the system determines that the equipment may have performance problems.

[0043] For fault information data, corresponding equipment fault records are directly generated according to the fault codes uploaded by the equipment. Each fault record includes the equipment ID, fault code, fault description, and fault occurrence time.

[0044] In a possible implementation manner, the equipment status monitoring adopts a real-time analysis method based on a time window. Specifically, the system analyzes and summarizes the uploaded data in units of a fixed time interval (such as 1 minute). The monitoring formula can be described as follows: Where: P success represents the transaction success rate; N success is the number of successful transactions within the statistical period; N total is the total number of transactions within the statistical period.

[0045] It can be understood that when P success <T threshold where T threshold is a preset threshold, such as 90%), the system will record a transaction performance alarm message and prompt the maintenance personnel to check the corresponding equipment.

[0046] As an extended approach, device status monitoring can be combined with historical data for trend analysis. For example, by comparing the transaction success rate in the current period with the average of the previous several periods, it is analyzed whether there is a downward trend in device performance. The specific calculation method is as follows: Where P success,current is the transaction success rate in the current statistical period, is the average transaction success rate in the previous N periods. If ΔP success < 0, it is prompted that the device performance may be gradually decreasing.

[0047] In some embodiments, the fault alarm function is implemented based on a real-time fault analysis model. Specifically, the system calculates the possibility of device faults by analyzing the uploaded fault information data and historical status data. Exemplarily, the calculation formula for the fault probability P(E failure ) is as follows: P(E failure ) = f(D history , C fault ) Where: D history is the historical operation status data of the device, including heartbeat records, transaction success rates, and previous fault information; C fault is the currently collected fault code; f(·) is a fault prediction model function, which can be a rule-based logical function or a prediction model obtained through machine learning training.

[0048] It should be noted that when P(E failure ) > T alarm (where T alarm is the threshold for fault alarm, for example, 80%), the system will trigger an alarm and generate a detailed fault report.

[0049] In an exemplary implementation, the alarm content includes the device ID, fault type, fault description, and recommended repair measures. For example: Alarm = {device ID: TVM001, fault type: communication anomaly, description: unable to connect to the network, recommendation: check the network interface}.

[0050] It can be understood that this alarm mechanism based on detailed fault information can not only remind the station management personnel to handle problems in a timely manner, but also provide specific troubleshooting suggestions for maintenance personnel, thereby improving the efficiency of fault handling.

[0051] In a possible optimization method, the present invention further supports hierarchical management of alarm information. Specifically: A first-level alarm indicates a critical failure of the device, such as a power module failure or hardware damage, which requires immediate handling; A second-level alarm indicates a device performance problem, such as a decrease in the transaction success rate, but it does not yet affect normal operation and can be handled during daily maintenance; A third-level alarm indicates a prompt for abnormal device status, such as a heartbeat packet delay, which can be automatically restored by the system.

[0052] This hierarchical management method helps station managers reasonably allocate maintenance resources and prioritize the handling of important device failure problems.

[0053] It should be further noted that the device status monitoring and fault alarm method is not only applicable to common devices such as TVM, AGM, and BOM in the AFC system, but can also be extended to intelligent terminal devices (such as automatic ticket gates, self-service terminals, etc.) in other traffic management systems. Through flexible monitoring strategies and efficient fault alarm mechanisms, the present invention can provide a strong guarantee for the safe and stable operation of the intelligent transportation system.

[0054] S4. Mode management: Adjust the operation mode of the station according to the operation requirements, including peak mode, off-peak mode, or specific event mode; In the present invention, mode management is one of the important steps of the AFC system station management method, which is used to dynamically adjust the operation mode of the system according to the operation requirements of the station, optimize the usage efficiency of device resources, and improve the passenger service experience. The mode management function can adapt to different scenario requirements, such as the fast passage requirements during peak passenger flow periods, the device energy-saving requirements during off-peak hours, and the specific configuration requirements during special events (such as sports events, large-scale activities). Through mode switching, the system can centrally control the operation status of various devices in the station and send mode change instructions to relevant devices and station-level subsystems to ensure the unity and reliability of the operation mode.

[0055] In this embodiment, the implementation of mode management specifically includes the following contents: As an option, the mode management in the present invention includes four main stages: mode definition, mode switching, mode parameter synchronization, and mode feedback, which correspond to different functional logics respectively.

[0056] Specifically, the mode definition stage includes the presets of peak mode, off-peak mode, and special event mode: Peak mode: Applicable to morning and evening peak hours, all TVM (self-service ticket vending machines), AGM (gate machines), and BOM (manual ticket vending machines) devices are in a fully open state to meet the large passenger flow passage requirements.

[0057] Low-Peak Mode: Applicable to periods with low passenger flow such as at night or during lunchtime on weekdays. Some equipment is suspended to reduce energy consumption. For example, only some AGM equipment is turned on to ensure basic passage functions.

[0058] Special Event Mode: Exemplarily, during large-scale events, the equipment can be flexibly configured according to the passenger flow direction. For example, two-way turnstiles can be set to one-way inbound mode, or standby TVM equipment can be temporarily enabled.

[0059] In a possible implementation, the mode switch is manually triggered by the operator through the main interface of the station management system. Specifically: After the operator logs in to the system and selects the target mode, the system verifies the operator's identity information, including username, password, and dynamic password.

[0060] After successful verification, the system sends a mode switch command to various devices in the station. The command content includes the mode type (such as Peak Mode), the list of target devices, and the operating status configuration.

[0061] It should be noted that the mode switch command is sent to the device through a standardized message protocol. For example, the format of the mode switch command can be expressed as: Command = {mode type, device list, configuration parameters} Where: The mode type is used to indicate the target mode of the switch; The device list includes all device IDs that need to adjust the status; The configuration parameters include the specific operating status (such as "normal operation" or "suspended service").

[0062] In some embodiments, the mode switch requires analyzing the station passenger flow data to select an appropriate mode. For example, the system automatically determines whether to switch to Peak Mode by analyzing the current passenger flow volume and predicted passenger flow trend within a certain time period. The prediction formula for passenger flow volume is as follows: P next = f(D history , F external ) Where: P next represents the passenger flow volume in the next time period; D history is the historical passenger flow data; F external is an external factor, such as weather, holiday, or event information.

[0063] It can be understood that when the predicted passenger flow volume exceeds the preset threshold, the system can prompt the operator to switch to Peak Mode; conversely, if the predicted passenger flow volume is low, it can be recommended to switch to Low-Peak Mode.

[0064] In an exemplary implementation, mode parameter synchronization ensures that all devices within a station maintain a consistent operating mode. Specifically, after sending a mode switching instruction, the central system verifies the execution status of the instruction through a device feedback mechanism. For example: after each device receives a mode switching instruction, it returns the execution status to the system, including flag information indicating success or failure.

[0065] The central system aggregates and analyzes the device feedback information. If it detects that some devices have not successfully switched, it resends the instruction.

[0066] It should be noted that mode parameter synchronization also supports multi-site linkage scenarios. For example, during a large passenger flow event, multiple stations on the same line need to switch to a special event mode simultaneously. The central system broadcasts the mode switching instruction to all relevant stations and monitors the execution progress of each station in real time.

[0067] In another possible implementation, the mode feedback function provides real-time query of the operating status. Specifically, the system supports operators to view the mode status of the current station through the management interface, including: The type of the switched mode; Statistics of the device status, such as "the number of devices that have been turned on" and "the number of devices with suspended operation"; Abnormal information that occurred during the mode switching process (such as a certain device not receiving the instruction).

[0068] Exemplarily, the output of the mode status query function can be expressed as: Mode_Status = {current mode, device statistics, abnormal records} It should be further noted that the mode management function of the present invention also supports mode history recording and mode backfilling functions: The mode history recording is used to track the historical switching situations of the station mode, including the switching time, operator information, and switching results.

[0069] The mode backfilling function is used to solve the problem of unsynchronized mode caused by network interruption or device failure. The operator can manually backfill the mode status of certain devices to ensure mode consistency.

[0070] It can be understood that these additional functions can improve the reliability and traceability of the system mode management and provide important support for the efficient operation of the station.

[0071] In extended applications, mode management is not only applicable to conventional AFC station devices but also can be extended to other transportation scenarios, such as an automatic ticket vending parking system or an airport security checkpoint management system. Through flexible mode definition and intelligent switching mechanisms, the present invention provides a unified solution for optimizing the operation of transportation devices in multiple scenarios.

[0072] S5, Data Cleaning and Analysis: Clean the stored operation status data, remove duplicate or abnormal data, and perform analysis based on the cleaned data to predict passenger flow or equipment usage requirements; In the AFC system station management method of the present invention, data cleaning and analysis is one of the key steps. Its function is to format, verify, and eliminate abnormal data from the operation status data uploaded by devices, and perform further analysis based on the cleaned high-quality data to support subsequent functions such as passenger flow prediction, equipment status evaluation, and resource allocation. Data cleaning mainly deals with the integrity, accuracy, and temporal consistency of data, while data analysis generates valuable information for station operation and equipment management through in-depth mining of the cleaned data.

[0073] It should be noted that the data cleaning and analysis method of the present invention combines fixed rule verification and dynamic model analysis, which can not only meet the basic quality requirements of data but also perform in-depth prediction and optimization for complex scenarios, thus ensuring the intelligence and efficiency of station management.

[0074] In this embodiment, the specific implementation of data cleaning and analysis includes the following: As an option, data cleaning first performs formatting processing and rule verification on the collected raw data. Specifically, formatting processing is to uniformly convert data from different sources into the standard format specified by the system, such as JSON format or XML format, for subsequent storage and analysis. Rule verification includes but is not limited to the following verification methods: Timestamp verification: Check whether the timestamps of transaction data or equipment status data are within a reasonable range. For example, the timestamps of all data should be later than the startup time of the device. If abnormal timestamps of data are found (such as future time or earlier than the device activation time), they will be marked as invalid data and eliminated.

[0075] Amount verification: Check the amount field of transaction data to ensure that the amount value is within the legal range defined by the system. For example, for the fare of a certain line, the amount value should be within the preset fare set {P 1 , P 2 , …, P n}, and the amount data outside the range will be eliminated.

[0076] Format verification: Check whether the data fields conform to the specified format. For example, whether the device ID is a fixed-length string, and whether the transaction record contains all necessary fields (such as time, ticket type, amount).

[0077] In some embodiments, to improve the efficiency and adaptability of data cleaning, the present invention adopts a dynamic cleaning rule generation mechanism. Specifically, the system automatically generates cleaning rules for specific fields based on historical data. For example: By analyzing the distribution law of historical transaction records, the upper and lower limit ranges of the amount field are dynamically adjusted.

[0078] For heartbeat packet data, a dynamic determination criterion for device online status is generated. For example, if a device loses heartbeat packets twice in a row, it can be regarded as normal fluctuation, but three or more times need to be marked as abnormal.

[0079] It can be understood that this dynamic cleaning rule generation mechanism can effectively improve the accuracy of data cleaning, especially having significant advantages in a large-scale and diverse device environment.

[0080] In a possible implementation manner, data analysis is processed based on the cleaned high-quality data. Specifically, the system first performs statistics and modeling on passenger flow data to achieve the prediction of passenger flow. The input of the passenger flow prediction model includes historical passenger flow data and external influencing factors, and the output of the model is the predicted value of the passenger flow in the next time period. The prediction formula can be described as follows: P next =f(D history ,F external ) Where: P next represents the predicted value of the passenger flow in the next time period; D history is the historical passenger flow data, usually including the number of people entering and leaving the station in the past few hours or days; F external represents external factors, such as weather conditions, holiday characteristics, or special event information.

[0081] It should be noted that the prediction model can be implemented using a linear regression model, a time series model (such as ARIMA), or a machine learning model (such as a neural network).

[0082] In some embodiments, to improve the reliability of the analysis results, the present invention also introduces an anomaly detection mechanism for identifying abnormal patterns in passenger flow data or device status data. For example, if the system discovers through statistical analysis that the transaction volume of a certain turnstile device has increased abnormally, it may indicate that there are problems such as duplicate records or malicious operation behaviors for this device. The calculation method for anomaly detection is as follows: Where: Z is the standardized anomaly score; X is the current data value; μ is the mean of the historical data; σ is the standard deviation of the historical data.

[0083] When the absolute value of Z exceeds a preset threshold (such as 3), it is determined that the data is abnormal and marked as invalid data.

[0084] As an extended method, the results of data analysis can be used for dynamic configuration of device resources. For example: The system adjusts the number of opened turnstile devices according to the passenger flow prediction results to cope with the upcoming passenger flow peak.

[0085] According to the distribution of transaction records, reasonably allocate the banknote and coin change resources of TVM devices to avoid equipment downtime caused by insufficient change during peak hours.

[0086] Exemplarily, the resource configuration optimization can be calculated by the following formula: R required =P next ·R per-Person Where: R required represents the resource demand, such as the number of change coins; P next is the passenger flow prediction value for the next time period; R per-Person is the single-person resource consumption, such as the average change amount.

[0087] It should be further noted that the data cleaning and analysis method in the present invention is not only applicable to the conventional devices of the AFC system (such as TVM, AGM, and BOM), but also can be extended to other traffic management scenarios (such as parking lot management, bus ticketing system, etc.). Through flexible cleaning rules and accurate analysis models, the present invention can provide reliable technical support for traffic data processing and intelligent management in multiple scenarios.

[0088] It can be understood that through the above data cleaning and analysis method, the system can continuously maintain high-quality data input, provide a solid foundation for the operation decision-making and resource optimization of the station, and thus significantly improve the overall operation efficiency and service level.

[0089] S6, Permission Management and Log Recording: Allocate permissions to system functions based on user roles and record the operation logs of users; In the AFC system station management method of the present invention, permission management and log recording are important functional modules to ensure the operation security and operation traceability of the system. Through permission management, the system can allocate corresponding functional permissions to different user roles, restrict users' access to unauthorized modules, and thus improve the overall security and controllability of the system. The log recording function is used to record each operation behavior of users in detail, including the operation time, operation type, and specific content, for subsequent auditing, problem troubleshooting, and responsibility tracing.

[0090] It should be noted that the permission management and log recording module is closely related to other functional modules. For example, the user's permissions directly affect their operation scope in the device status monitoring, mode management, and revenue ticketing management modules. At the same time, log recording, as the "historical track" of system operation, provides an important reference basis for maintenance management personnel.

[0091] In this embodiment, the specific implementation of permission management and log recording includes the following: As an option, permission management is designed based on user roles, and the role-based access control (RBAC) model is used to allocate functional permissions. Specifically, the system pre-defines a set of accessible functional modules for each role. For example: Station master role: Has the highest permissions and can access all functional modules, including device status monitoring, mode management, data management, etc.

[0092] Device maintenance staff role: Only allowed to access the device status monitoring module and the fault alarm module.

[0093] Financial management role: Mainly used to access the revenue management and ticketing management modules and cannot view the content of the device monitoring module.

[0094] In a possible implementation manner, permission management is achieved through dynamic loading. When a user logs in to the system, the system loads the corresponding functional permissions according to their role and generates a personalized main interface. Exemplarily, the logic for loading permissions can be expressed as: F user =F system ∩P role Where: F user Is the set of available functions for the user; F system Is the set of all functions provided by the system; P role Is the set of permissions corresponding to the role to which the user belongs.

[0095] It should be noted that the user's function menu will be dynamically adjusted according to their permissions. For example, unauthorized functional modules will be hidden or grayed out to prevent illegal access.

[0096] In some embodiments, to improve the flexibility of permission management, the present invention allows administrators to customize the role permissions. For example, the system provides a role management interface where the administrator can select a role and check or uncheck the functional permissions of that role. The modified permission configuration will take effect in real time and be recorded in the system.

[0097] Specifically, the storage of role permissions adopts a structured format, as shown in the following example: Role_Config = {role ID, function list, modification time} Among them, the "function list" field records the identifiers of all function modules that the role is authorized to access.

[0098] In terms of the log recording function, the present invention details the key information of each user operation through the operation log recording module. It should be noted that the operation log recording is not limited to normal user operations, but also includes abnormal operations (such as login failures, multiple attempts of illegal access) and system events (such as mode switching, device status change).

[0099] Specifically, the recorded content of the operation log includes but is not limited to: User ID: Identifies the user who performs the operation; Operation time: Records the specific time when the operation occurs; Operation type: Identifies the specific operation behavior, such as "login", "switch mode", "modify parameters", etc.; Operation content: Records the detailed information of the operation, such as which parameters are modified and which devices the commands are executed on.

[0100] In an exemplary implementation, the storage format of the operation log can be in JSON format for subsequent query and auditing. For example: Log E ntry = {user ID: U001 time: 2024-12-29 10:30:00, type: login, status: successful} As a possible optimization method, the present invention supports the real-time log monitoring function. Specifically, the system provides an administrator with a real-time log viewing interface, displays the recent operation records, and supports filtering and searching functions. For example, the administrator can filter the operation logs by time period or user ID to quickly locate specific operation behaviors.

[0101] It should be noted that the storage of the operation log adopts a hierarchical archiving mechanism. Exemplarily, the system stores the logs of the most recent 30 days in the main database to support real-time query, while the historical logs are archived monthly to the backup server to reduce the pressure on the main database.

[0102] In some embodiments, the log recording module of the present invention also provides an abnormal behavior detection function. For example, the system identifies possible abnormal login attempts (such as multiple failed logins within a short period of time) by statistically analyzing the login behavior of users. The determination logic of the abnormal behavior detection can be described as follows: E abnormal = If Nfailures >T threshold Wherein: N failures represents the number of failed logins of the user within a unit time; T threshold is the threshold value set by the system, such as 5 times.

[0103] When detecting abnormal behavior, the system will automatically lock the relevant accounts and trigger an alarm to prevent potential malicious attacks.

[0104] It should be further noted that the permission management and log recording functions of the present invention are not only applicable to the conventional scenarios of the AFC system, but can also be extended and applied to other intelligent management systems, such as parking lot management systems, transportation hub management platforms, etc. Through flexible permission configuration and detailed operation records, the present invention can significantly improve the security and operation controllability of the system.

[0105] S7, Revenue and Ticket Management: Record the station revenue and ticket information; In the station management method of the AFC system of the present invention, revenue and ticket management is an important link to ensure the normal operation of the station and financial transparency. By recording and dynamically updating the information on the receipt, surrender, inventory, and revenue of tickets within the station, the system can timely master the flow situation of tickets and the revenue status, so as to provide reliable financial management support for station management personnel. Revenue management involves the precise management of cash and tickets, while ticket management covers the allocation of tickets, inventory update, and historical record query.

[0106] It should be noted that there is a close relationship between revenue and ticket management and other modules. For example, the equipment status monitoring module (step S3) provides the operating status of ticket-selling equipment (such as TVM, BOM, etc.), and the mode management module (step S4) can affect the working configuration of ticket-selling equipment, thereby indirectly affecting the recording of ticket flow and revenue data.

[0107] In this embodiment, the specific implementation of revenue and ticket management includes the following content: As an option, the revenue management of the present invention is based on the real-time collection and classification summary of transaction data. Specifically, the system analyzes the transaction records from TVM (self-service ticket vending machine) and BOM (manual ticket vending machine), and classifies and statistics them according to transaction type, amount, and ticket type.

[0108] In a possible implementation manner, the system calculates the total daily revenue through a formula, and the formula is as follows: Wherein: R total is the total daily revenue; R transaction,i is the revenue amount for the i-th transaction; N is the total number of transactions on the day.

[0109] It can be understood that this calculation method supports the revenue calculation of multiple transaction types, including cash payment, electronic payment, and other payment methods.

[0110] Specifically, the ticket management function covers operations such as ticket requisition, return, transfer, and inventory update. In an exemplary implementation, the dynamic update formula for ticket inventory is as follows: I remaining = I initial + I returned - I issued Where: I remaining is the current inventory; I initial is the initial inventory; I returned is the number of tickets returned; I issued is the number of tickets requisitioned.

[0111] As an extended function, the present invention supports the combined operations of ticket requisition and return. For example, during peak periods, BOM operators can requisition multiple types of tickets at once, and the system will calculate the inventory changes separately according to the types of different tickets.

[0112] In terms of ticket transfer, the present invention provides ticket transfer functions within the station and between stations. Specifically: Transfer within the station: The system allows ticket transfer between different ticket storage points, and automatically updates the corresponding inventory records after the operation is completed.

[0113] Transfer between stations: When there is a surplus or shortage of tickets between stations, the system generates a transfer plan and sends it to the relevant stations. Exemplarily, the inter-station transfer record includes the transfer station, transfer time, ticket type, and quantity.

[0114] It should be noted that after the inter-station transfer is completed, the system will synchronously update the inventory information of the source station and the destination station, and generate a transfer record for subsequent query.

[0115] In the management of revenue data, the system separately statistics cash revenue and non-cash revenue. As a possible implementation, the statistics of cash revenue includes the cash receipt records of each device. For example, for TVM devices, the system records the total daily cash amount of ticket sales and the specific quantities of coin and bill change.

[0116] The management of non-cash proceeds is mainly for electronic payment records. The system generates a unique identifier for each electronic payment transaction and stores it in association with the ticket ID and transaction amount. For example, the electronic payment record format is as follows: E_Payment = {transaction ID, card ID, payment amount, payment time} Understandably, this management approach of distinguishing between cash and non-cash proceeds helps improve financial transparency and support the reconciliation needs of multiple payment methods.

[0117] In some embodiments, the ticket management function also includes ticket inventory and historical record query. Specifically: Inventory counting: The operator can query the inventory status of all current tickets through the system and perform inventory counting operations on the selected tickets. For example, after entering the actual number of inventory counts, the system automatically calculates the difference between the inventory count results and the system records and generates an inventory count report.

[0118] History query: The system supports filtering history records by time period, ticket type, and operation type. For example, administrators can query ticket collection records for the past month to analyze ticket circulation trends.

[0119] It should be noted that the inventory count and history query functions ensure the traceability of ticket management and the accuracy of data through detailed log records.

[0120] In a possible optimization mode, the present invention also supports batch import and export functions of ticket card data. For example, when batches of tickets are turned in, the operator can select the corresponding ticket card file for import, and the system automatically parses the file content and updates the inventory information. The data format of the exported ticket card can be Excel or CSV format to facilitate data sharing and analysis between stations.

[0121] It should be further explained that the revenue and ticket management function of the present invention also supports abnormality detection and automatic reminders. For example: The system analyzes historical transaction data to detect whether the cash collection of a certain device is abnormal (such as low or high cash amount).

[0122] When the ticket inventory is insufficient, the system automatically reminds the operator to replenish the inventory.

[0123] These functions effectively improve the intelligence level of revenue and ticketing management, ensuring the smooth operation of stations and the accuracy of revenue data.

[0124] S8. Report generation and data export: Generate operational reports based on the cleaned data and export the data in the form of electronic files.

[0125] In the AFC system station management method of the present invention, the report generation and data export functions are important components for realizing system data visualization and operation analysis. Through comprehensive analysis of the system operation status, revenue information, passenger flow data, and equipment status, structured reports are generated to provide multi-dimensional decision-making support for station management personnel. At the same time, the system supports the export of various report formats and customized filtering, facilitating management personnel to use in different scenarios or share data with other systems.

[0126] In this embodiment, the specific implementation of report generation and data export includes the following: As an option, the system provides various report types according to data types and user requirements, including but not limited to: Revenue report: Statistics of ticket sales revenue, cash revenue, and electronic payment revenue within a certain period.

[0127] Passenger flow report: Display the changes in passenger flow at different times in the station, including inbound, outbound, and transfer flows.

[0128] Equipment status report: Record the operation time, failure times, and maintenance history of equipment.

[0129] Operation log report: Summarize the operation behaviors of system users, including mode switching, parameter adjustment, etc.

[0130] In a possible implementation manner, report generation adopts a dynamic template mechanism. Specifically, the system dynamically constructs the report structure according to the selected report type and filtering conditions by the user. For example: When the user selects a revenue report and filters the time range as "from December 1, 2024 to December 31, 2024", the system will generate the corresponding revenue data and statistically summarize it by day.

[0131] The report structure includes a title part, a filtering condition part, and a data display part, and supports further graphical display, such as generating a line chart or a bar chart.

[0132] It should be noted that the core of report generation lies in the calculation and classification of basic data. For example, for the revenue report, the system first statistically analyzes the cleaned transaction records and then calculates the daily revenue by grouping according to time. The revenue statistical formula is as follows: Where: R daily Is the daily revenue; R transaction,i Is the amount of the i-th transaction; N is the total number of transactions on the day.

[0133] In another possible implementation, the generation of the passenger flow report is based on historical passenger flow data. The system counts the number of passengers entering and leaving each turnstile by time period (such as hours or days), and aggregates the data into a passenger flow report for the entire station. Exemplarily, the passenger flow statistical formula is: Where: P station,t is the total passenger flow of the station in time period t; P device,t,i is the passenger flow of the i-th device in time period t; M is the total number of devices.

[0134] In some embodiments, to improve the readability of the report, the present invention supports a chart display function. For example: The revenue report can generate a bar chart to show the change in the amount of ticket sales in different time periods.

[0135] The passenger flow report can generate a line chart to intuitively show the change trend of the all-day passenger flow.

[0136] It should be noted that these chart display functions are implemented through visualization tools, and the operator can select the chart type (such as bar chart, pie chart, line chart) and preview the generation result in real time.

[0137] In terms of data export, the present invention supports the report export function in multiple file formats. For example: Export to Excel format: It is convenient for the operator to further process and analyze the report data.

[0138] Export to PDF format: It is convenient for the archiving and distribution of the report.

[0139] Export to CSV format: It is convenient for data docking with other systems.

[0140] As a possible implementation, the system allows users to customize the exported content, such as selecting the fields to be exported, the sorting rules, and the time range. Exemplarily, the operator can choose to only export the "time period" and "number of inbound passengers" fields in the passenger flow report and ignore other content.

[0141] In some embodiments, the present invention also supports the automatic generation and distribution of reports. For example: The system allows the administrator to set the generation frequency of the report (such as daily, weekly, or monthly) and the distribution method (such as sending by email to the specified personnel).

[0142] The time of report generation can be synchronized with the operation cycle of the system. For example, the revenue report for the current day is automatically generated after the daily operation ends.

[0143] It is understandable that such an automated function can significantly reduce the manual operations of operators and improve work efficiency.

[0144] In an extended application, the report generation and data export functions of the present invention can also be integrated into other systems. For example, it can be docked with a financial management system to automatically import the revenue report into the financial system for accounting processing. Exemplarily, such integration can be achieved through an API, and the data transmission format can be JSON or XML.

[0145] It should be further noted that the report generation and data export functions of the present invention can restrict the scope of user access to reports according to permissions. For example, the station master role can generate all reports, while the equipment maintenance staff role can only generate equipment status reports. By combining the permission management function, the system ensures the security and controllability of data.

[0146] An AFC system station management device, comprising: A data acquisition module: used to acquire the operation status data of various devices in the AFC system, and the operation status data includes the online status of the device, transaction records, and fault information; A data transmission module: used to upload the operation status data to the central control system through a communication network; A data storage module: used to store the acquired operation status data; A status monitoring module: used to monitor the device status in real time and calculate the probability of device failure based on the operation status data. If the failure probability exceeds a preset threshold, an alarm signal is triggered; A mode management module: used to send an operation mode switching instruction to the device according to the station operation requirements; A data cleaning module: used to perform rule verification and abnormal data elimination on the stored operation status data; A permission management module: used to allocate function permissions according to user roles and record operation logs; A report generation module: used to generate operation reports based on the stored data. An electronic device, comprising: A processor; A memory; A program stored in the memory and running on the processor, and the program is used to implement the steps of the AFC system station management method.

[0147] Although the embodiments of the present invention have been shown and described, for those of ordinary skill in the art, it can be understood that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirits of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. AFC system station management method, characterized in that: The following steps are involved: Equipment status data collection: The operating status data of various equipment in the AFC system are collected through embedded sensors. The operating status data includes the online status, transaction records, and fault information of the equipment; Data transmission and storage: The collected operating status data is uploaded to the central control system through an optimized data transmission protocol and stored in the database; Equipment status monitoring and fault alarm: Based on the operating status data, the operating status of the equipment is monitored, and if an equipment abnormality is detected, an alarm is triggered; Mode management: adjust the station's operating mode according to operational needs, including peak mode, off-peak mode or specific event mode; Data cleaning and analysis: Clean the stored operation status data, remove duplicate or abnormal data, and analyze the cleaned data to predict passenger flow or equipment usage needs; Permission management and logging: assign permissions to system functions based on user roles and record user operation logs; Revenue and ticketing management: record station revenue and ticketing information; Report generation and data export: Generate operational reports based on the cleaned data and export the data in electronic file form.

2. The AFC system station management method according to claim 1, characterized in that: The device status monitoring comprises the following steps: Based on historical operating status data, the probability of equipment failure is calculated through a prediction model. If the failure probability exceeds the preset threshold, an alarm signal is triggered; After a fault alarm occurs, the operator will be provided with the location information of the faulty equipment and the type of fault.

3. The AFC system station management method according to claim 1, characterized in that: The mode management includes the following steps: After the operator enters the password to verify his identity, the system sends a mode switching instruction; The mode switching instructions include control instructions for batch adjustment of the operating status of various types of equipment, and the control instructions involve suspending service, operating normally, or switching to a bidirectional mode of the equipment.

4. The AFC system station management method according to claim 1, characterized in that: The data cleaning comprises the following steps: Perform rule verification on the timestamp, amount and data format in the transaction records, and remove transaction records that do not comply with the rules; Carry out passenger flow forecast based on the cleaned data, and dynamically adjust the number of devices turned on by combining historical passenger flow and external factors.

5. The AFC system station management method according to claim 1, characterized in that: The rights management includes the following steps: Configure a permission set according to the user role, wherein the permission set defines the functional modules that the user can operate; User permissions are dynamically loaded by the central system and displayed in the form of a function menu on the system main interface; The operation log records the user's operator number, operation time, operation type and specific operation content.

6. The AFC system station management method according to claim 1, characterized in that: The revenue and ticketing management includes: Record the use and surrender information of tickets according to the actual operational needs of the station; The inventory quantity of station tickets is dynamically updated. The inventory quantity of tickets is the initial inventory minus the number of tickets already issued plus the number of returned tickets.

7. The AFC system station management method according to claim 1, characterized in that: The report generation comprises the following steps: Based on the cleaned operation data, generate equipment status reports, passenger flow statistics reports and revenue reports according to screening conditions; Supports exporting generated reports in Excel or PDF electronic file formats.

8. The AFC system station management method according to claim 1, characterized in that: The fault alarm comprises the following steps: Calculate the equipment's operating stability index based on the real-time collected equipment operating status data; Compare the operation stability index with a preset normal operation threshold, and trigger an alarm if the equipment operation stability is lower than the threshold; The alarm information includes the equipment's fault location, fault type, and abnormal operation data; The system automatically generates maintenance suggestions based on the type of equipment failure and sends the suggestions to the maintenance personnel's terminal device.

9. AFC system station management device, based on the AFC system station management method according to any one of claims 1 to 8, characterized in that: include: Data collection module: used to collect the operating status data of various devices in the AFC system, including the online status, transaction records and fault information of the devices; Data transmission module: used to upload the operation status data to the central control system through the communication network; Data storage module: used to store the collected operation status data; Status monitoring module: used to monitor the status of equipment in real time and calculate the probability of equipment failure based on the operating status data. If the probability of failure exceeds the preset threshold, an alarm signal is triggered; Mode management module: used to send operation mode switching instructions to the equipment according to station operation requirements; Data cleaning module: used to perform rule verification on the stored operation status data and remove abnormal data; Permission management module: used to assign functional permissions based on user roles and record operation logs; Report generation module: used to generate operational reports based on stored data.

10. An electronic device, characterized in that: include: processor; Memory; A program stored in the memory and running on the processor, wherein the program is used to implement the steps of any one of the methods of claims 1 to 8.

Images