Parking flow processing method and system based on multi-device cooperative co-management

Abstract

The invention provides a parking flow processing method and system based on multi-device cooperative co-management, and relates to the technical field of data processing, and the method comprises the steps: obtaining multi-device release event data and multi-device attribute data through an event release layer; constructing an adaptive learning module; building a multi-source pipeline fusion engine, and performing parking pipeline fusion analysis on the multi-device release event data, the multi-device attribute data and the adaptive learning module to obtain parking pipeline processing data; and a data storage and business system is adopted to carry out storage cooperative work on multi-device release event data and parking flow processing data. The technical problems that in the prior art, due to the fact that an intelligent cooperation and complementary fusion mechanism is lacked between multi-source heterogeneous sensing devices, processing logic is rigid, the conflict resolution capacity is insufficient, and the accuracy of parking flow data is affected are solved, a multi-device cooperation co-management mechanism is constructed, management of parking records in a complex scene is achieved, and the parking flow data processing efficiency is improved. And the accuracy of parking flow data is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a parking flow processing method and system based on multi-device collaborative management. Background Technology

[0002] In smart parking management, the digitization of a complete parking cycle is the foundation for billing and management. Modern parking lots typically deploy various types of sensing devices to cover different areas and functions, forming a multi-source heterogeneous data network. However, each of these devices has its inherent physical limitations: high-position video can identify license plates, but suffers from processing delays and decreased confidence levels in inclement weather; geomagnetic sensors can detect vehicle occupancy in milliseconds, but cannot provide license plate information; handheld PDAs can provide final human confirmation, but suffer from delays and cannot provide real-time coverage.

[0003] Currently, there are two main technical solutions for processing multi-source parking data: one relies on a single authoritative device, designating data from a specific type of device as the authoritative basis, with data from other devices used only as reference. This approach is simplistic and crude, but completely ignores the value of data from other devices, and if the authoritative device fails, the recording for the entire area will be interrupted. The other approach is a single-threaded event processing method based on predefined rules. Although it can receive data from multiple devices, its processing logic is rigid, typically processing events sequentially and unable to dynamically adjust according to real-time scenarios and device status. Neither of these methods establishes intelligent collaborative relationships between devices, fails to leverage device characteristics to achieve complementary advantages, resulting in limited processing capabilities in complex real-world scenarios, high costs for manual intervention, and difficulty in ensuring the consistency and reliability of parking flow data.

[0004] In summary, existing technologies suffer from technical problems due to the lack of intelligent collaboration and complementary integration mechanisms among multi-source heterogeneous sensing devices, resulting in rigid processing logic and insufficient conflict resolution capabilities, which further affect the accuracy of parking flow data. Summary of the Invention

[0005] The purpose of this application is to provide a parking flow processing method and system based on multi-device collaborative management, in order to solve the technical problem in the prior art that the lack of intelligent collaboration and complementary integration mechanism among multi-source heterogeneous sensing devices leads to rigid processing logic and insufficient conflict resolution capabilities, which further affects the accuracy of parking flow data.

[0006] To achieve the above objectives, this application provides a parking flow management method and system based on multi-device collaborative management.

[0007] Firstly, this application provides a parking flow processing method based on multi-device collaborative management. This method is implemented through a multi-device collaborative management parking flow processing system. The method includes: acquiring multi-device published event data and multi-device attribute data through an event publishing layer, wherein the event publishing layer consists of all heterogeneous sensing devices, and the multi-device attribute data includes device type, collaborative role, and data quality indicators; constructing an adaptive learning module, which includes a dynamic priority evaluation model and an intelligent complementary decision model, wherein the dynamic priority evaluation model uses a gradient boosting decision tree, and the intelligent complementary decision model uses a long short-term memory network; building a multi-source flow fusion engine, using this engine to perform parking flow fusion analysis on the multi-device published event data, multi-device attribute data, and the adaptive learning module to obtain parking flow processing data; and using a data storage and business system to perform collaborative storage of the multi-device published event data and the parking flow processing data.

[0008] Optionally, the specific steps for constructing a dynamic priority evaluation model are as follows: acquiring historical parking records and standard event data; identifying input and output features of the historical parking records and standard event data to obtain an evaluation input feature sample set and an evaluation output feature sample set; and using a gradient boosting decision tree to perform offline training and periodic updates on the evaluation input feature sample set and the evaluation output feature sample set to construct a dynamic priority evaluation model.

[0009] Optionally, the evaluation input feature sample set specifically includes: environmental features, equipment static features, equipment dynamic features, and event features, and the evaluation output feature sample set is a dynamic priority weight between 0.0 and 1.0.

[0010] Optionally, the specific steps for constructing an intelligent complementary decision-making model are as follows: obtaining a parking decision dataset, which is a sequence of historical events containing complementary operations and not containing complementary operations; identifying the input and output features of the parking decision dataset to obtain a decision input feature sample set and a decision output feature sample set; and training and updating the decision input feature sample set and the decision output feature sample set using a long short-term memory network to construct an intelligent complementary decision-making model.

[0011] Optionally, the decision input feature sample set is a time-ordered sequence of events, each event containing its device type, event type, and data quality index, and the decision output feature sample set is a complementary decision instruction.

[0012] Optionally, the multi-source pipeline fusion engine specifically includes: an event standardization and preprocessing module, used to parse events from different sources, including timestamp unification, license plate number standardization, and data validity verification; an intelligent collaboration and complementary matching module, used to, when a new event is received, call the dynamic priority evaluation model to calculate a real-time dynamic weight for the event, call the intelligent complementary decision model, input the most recent event sequence, and determine whether to start the complementary process; a multi-level priority conflict resolution module, used to escalate the decision logic when multiple candidate records are matched or conflicts occur, and follow the principle of high priority over low priority in decision-making; a special business processing module, used to intelligently handle turnaround, inspection, and abandoned vehicle scenarios according to configured parameters; and a state machine manager, used to define the state for each parking record and ensure the atomicity of state transitions through distributed locks.

[0013] Optionally, the principle of high priority over low priority is as follows: First layer of collaborative role priority: MANUAL_AUDITOR > PRIMARY_VERIFIER > TRIGGER > STATUS_SENSOR; Second layer of dynamic priority weight: within the same collaborative role, compare the dynamic weights calculated by the model and decide the one with the higher weight; Third layer of static individual priority: when the first two layers are the same, compare the static priority of the device.

[0014] Optionally, the event publishing layer further includes an event bus, which serves as the central nervous system of the system and is responsible for receiving, caching, and distributing events.

[0015] Secondly, this application also provides a parking flow processing system based on multi-device collaborative management, used to execute the parking flow processing method based on multi-device collaborative management as described in the first aspect. The parking flow processing system based on multi-device collaborative management includes: a data acquisition unit, used to acquire multi-device published event data and multi-device attribute data through an event publishing layer, wherein the event publishing layer consists of all heterogeneous sensing devices, and the multi-device attribute data includes device type, collaborative role, and data quality indicators; a model building unit, used to build an adaptive learning module, the adaptive learning module including a dynamic priority evaluation model and an intelligent complementary decision model, wherein the dynamic priority evaluation model uses a gradient boosting decision tree, and the intelligent complementary decision model uses a long short-term memory network; a parking flow fusion analysis unit, used to build a multi-source flow fusion engine, using the multi-source flow fusion engine to perform parking flow fusion analysis on the multi-device published event data, multi-device attribute data, and the adaptive learning module to obtain parking flow processing data; and a collaborative storage unit, used to perform collaborative storage work on the multi-device published event data and the parking flow processing data using a data storage and business system.

[0016] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0017] The system acquires multi-device event data and multi-device attribute data through an event publishing layer, which consists of all heterogeneous sensing devices. The multi-device attribute data includes device type, collaborative role, and data quality indicators. An adaptive learning module is constructed, comprising a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model uses a gradient boosting decision tree, and the intelligent complementary decision model uses a long short-term memory network. A multi-source flow fusion engine is built to perform parking flow fusion analysis on the multi-device event data, multi-device attribute data, and the adaptive learning module, yielding parking flow processing data. A data storage and business system is used to collaboratively store the multi-device event data and the parking flow processing data. In other words, by establishing a collaborative working model among devices, different types of devices can participate in the identification of parking events based on their respective expertise. An adaptive priority model based on machine learning and an intelligent fusion algorithm based on machine learning are designed. When resolving conflicts, the dynamic weights output by the model are used as the decision-making basis, making the decision more scientific and adaptive. Through a distributed state machine and recording all change events, data consistency and complete traceability under high concurrency are ensured, enabling the management of parking records in complex scenarios and improving the accuracy of parking flow data.

[0018] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the parking flow management method based on multi-device collaborative management in this application.

[0021] Figure 2This is a schematic diagram of the parking flow water treatment system based on multi-device collaborative management in this application.

[0022] Figure labeling: Data acquisition unit 11, model building unit 12, parking flow fusion analysis unit 13, collaborative storage unit 14. Detailed Implementation

[0023] This application provides a parking flow processing method and system based on multi-device collaborative management, solving the technical problem in existing technologies where the lack of intelligent collaboration and complementary fusion mechanisms among multi-source heterogeneous sensing devices leads to rigid processing logic, insufficient conflict resolution capabilities, and further affects the accuracy of parking flow data. By establishing a collaborative working model among devices, different types of devices can participate in the identification of parking events based on their respective expertise. An adaptive priority model based on machine learning and an intelligent fusion algorithm based on machine learning are designed. During conflict resolution, the dynamic weights output by the model are prioritized as the decision-making basis, making the decision more scientific and adaptive. Through a distributed state machine and recording all change events, data consistency and complete traceability under high concurrency are ensured, enabling the management of parking records in complex scenarios and improving the accuracy of parking flow data.

[0024] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be understood that this application is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. It should also be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all of them.

[0025] Example 1, please refer to the appendix. Figure 1 This application provides a parking flow management method based on multi-device collaborative management, wherein the parking flow management method based on multi-device collaborative management is applied to a parking flow management system based on multi-device collaborative management, and the parking flow management method based on multi-device collaborative management specifically includes the following steps:

[0026] S100: Obtain multi-device published event data and multi-device attribute data through the event publishing layer, wherein the event publishing layer is composed of all heterogeneous sensing devices, and the multi-device attribute data includes device type, collaborative role, and data quality indicators.

[0027] Furthermore, this application also includes the following steps: the event publishing layer further includes an event bus, which serves as the central nervous system of the system and is responsible for receiving, caching, and distributing events.

[0028] Specifically, the event publishing layer is the logical layer in the parking management system responsible for the collection and reporting of raw data. It doesn't refer to a specific software or hardware component, but rather to a unified data access plane comprised of all on-site sensing devices and their data reporting interfaces. Its core function is to receive information from different sources in a standardized manner. When publishing an event, each device, in addition to standard data, also carries its own device type, collaborative role, and data quality indicators, such as confidence level and response time. The event release layer consists of all heterogeneous sensing devices, which are field detection devices with different physical principles, functional characteristics, and data formats. These include high-position video cameras, handheld PDAs, geomagnetic sensors, inspection vehicles, and integrated barrier gate machines. High-position video cameras are video devices consisting of at least one bullet camera and at least one PTZ camera, mounted on a 6-8 meter high pole, which detect vehicles and license plates through image recognition algorithms. Geomagnetic sensors are sensors buried under parking spaces, which detect the presence of vehicles' metal bodies by detecting changes in the Earth's magnetic field. Handheld PDAs are mobile terminals carried by inspection personnel for manually confirming parking space status, license plate information, or handling anomalies. Integrated barrier gate machines are devices at the parking lot entrances and exits, integrating license plate recognition and gate control.

[0029] Multi-device event data and multi-device attribute data are obtained through the event publishing layer. Multi-device event data consists of business messages proactively reported by various devices when they detect changes in status. Multi-device attribute data is metadata reported along with each event data entry, describing the characteristics and status of the data source itself, including device type, collaborative role, and data quality indicators. Device type specifies whether the data source is high-resolution video, geomagnetic sensors, or a PDA, etc. Collaborative role is a predefined functional label in the system, representing the authority and function of the device in the collaborative management model. For example, a primary verifier indicates that the device is typically used for critical judgments; a status sensor indicates that its data is used to assist in status perception; and a human auditor indicates that the data comes from final human confirmation and has the highest authority. Data quality indicators are parameters used to quantitatively evaluate the credibility of this event data. The most common indicator is confidence level, which is the degree of certainty that the device's own algorithm is about the identification result, usually expressed as a decimal between 0 and 1.

[0030] When a vehicle enters a parking space, different devices asynchronously detect this change. The high-position video recognition algorithm analyzes the captured image; if it identifies the license plate, it generates an event containing the license plate number, time, and location, along with a confidence score, such as 0.95. Almost simultaneously, the geomagnetic sensor under the parking space detects a sudden change in the magnetic field, generating a parking space occupancy event. Because its principle is physical detection, its confidence score is usually marked as a near-definite value, such as 0.99. After generation, these events are immediately encapsulated by their respective device agent programs. During encapsulation, key attribute data is injected into each event. For example, it indicates which high-position video camera it originated from, its cooperating role being the primary verifier, and its recognition confidence score being 0.95; or it indicates that it originated from the geomagnetic sensor with serial number XYZ, its role being a status sensor, and its confidence score being 0.99. Subsequently, these standardized and encapsulated event messages are sent to a message queue or event bus, thus completing the transformation from raw physical signals to system events rich in semantic information, providing a complete information package containing both event data and attribute data for subsequent intelligent fusion.

[0031] An event bus is a core component of a software architecture pattern, acting as a unified transmission hub for all event data. Its technical essence is typically a high-throughput, distributed, and persistent message queue system. It doesn't concern itself with the specific business content of events, but rather, like a post office or express sorting center, provides a reliable channel and routing service for event transmission. S200: Construct an adaptive learning module, which includes a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model uses a gradient boosting decision tree, and the intelligent complementary decision model uses a long short-term memory network. The event bus, as the central nervous system of the system, is responsible for the reception, caching, and distribution of events. Receiving is the unified access point provided by the event bus, such as an API or port, allowing agents from all heterogeneous sensing devices to send encapsulated event messages to the bus without knowing who will process them downstream; caching is the event bus's ability to persistently store event messages. When an event is sent to the bus, it is stored on disk or in memory for a period of time until it has been processed by all consumers that need it, ensuring that no events are lost even when the system's backend processing modules are temporarily busy or restarting; distribution is the event bus actively pushing or passively waiting to pull received events to one or more consumer modules that are interested in such events, such as a multi-source pipeline fusion engine, according to preset topics or routing rules.

[0032] When the agent program of high-position video, geomagnetic sensors, and other devices generates a structured event with attributes, it does not directly call the interface of the backend processing module. Instead, it simply publishes this event as a message to a specific topic on the event bus. Upon receiving the message, the event bus service first persists it to a disk log and returns a successful reception acknowledgment to the sender, ensuring no data loss. Subsequently, the multi-source pipeline fusion engine, as the core processing unit of the system, subscribes to this topic as a consumer. The event bus pushes messages to the fusion engine one by one or in batches according to the strict order of event arrival. This means that the sensing devices (producers) and the processing engine (consumers) are completely decoupled: the devices do not need to know the engine's IP address or status, and the engine does not need to actively poll hundreds of devices. The bus handles all network communication, load balancing, and fault recovery. For example, when the fusion engine needs to be expanded, it only needs to start a new instance and subscribe to the same topic; the event bus will automatically distribute messages among different instances to achieve load balancing. The entire system, through this central nervous system, achieves centralized control, elastic scaling, and reliable transmission of data flow.

[0033] S200: Construct an adaptive learning module, which includes a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model uses a gradient boosting decision tree, and the intelligent complementary decision model uses a long short-term memory network.

[0034] Furthermore, S200 of this application includes the following specific steps for constructing a dynamic priority evaluation model: acquiring historical parking records and standard event data; identifying input and output features of the historical parking records and standard event data to obtain an evaluation input feature sample set and an evaluation output feature sample set; and using a gradient boosting decision tree to perform offline training and periodic updates on the evaluation input feature sample set and the evaluation output feature sample set to construct a dynamic priority evaluation model.

[0035] Furthermore, this application also includes the following steps: the evaluation input feature sample set specifically includes: environmental features, device static features, device dynamic features and event features, and the evaluation output feature sample set is a dynamic priority weight between 0.0 and 1.0.

[0036] Specifically, the adaptive learning module comprises two key models: a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model employs gradient boosting decision trees, such as XGBoost or LightGBM, which effectively handles tabular data, integrates multiple features, and offers good interpretability. The evaluation input feature sample set includes environmental features, device static features, device dynamic features, and event features. Environmental features include time (hour / peak hours), weather (sunny / rainy / snowy), and light intensity. Device static features include device type, device model, and installation location. Device dynamic features include the device's average response time over the past hour, recognition success rate over the past 24 hours, and number of offline events. Event features include the confidence level of the current event. The evaluation output feature sample set is a dynamic priority weight between 0.0 and 1.0, which replaces the static priority value. 1.0 indicates that under all current conditions, the event should be fully accepted; 0.0 indicates that it should be completely ignored; and 0.65 indicates a moderately high confidence level, which may require consideration in conjunction with other events. The model is trained offline using historical parking records and event data that was eventually adopted as the gold standard, and is updated regularly (e.g., weekly) with new data to adapt to environmental and equipment aging.

[0037] In other words, training data is accumulated, including millions of historical parking records accumulated over the past few months, and standard event data filtered from them that has been verified as accurate by the business, such as events corresponding to records that were successfully billed without dispute. Next, feature engineering is performed: for each standard event data point, based on its occurrence time, weather logs, device profile, and performance monitoring data at the time, corresponding environmental, static device, dynamic device, and event features are extracted to form a multi-dimensional feature vector, which serves as the evaluation input feature sample set. Simultaneously, an output label is assigned to this sample: since it is ultimately adopted, in an ideal model, it should receive a high weight, typically set to 1.0. Events that are not adopted or lead to errors have lower output labels. Then, the gradient boosting decision tree algorithm is used to learn from the training set consisting of millions of such feature vectors and weight label samples on an offline server. The algorithm automatically discovers complex patterns such as the weakening influence of video confidence on the final weight when the light intensity is below 300 lux, or the systematic discounting of event weights when the device has a latency exceeding 500 milliseconds in the past hour. Once the model is trained, it will be deployed online. The model will be incrementally updated or retrained periodically (e.g., weekly) using the latest data to capture slow trends such as device aging and seasonal changes. When a new event occurs in the online system, its feature vector is extracted in real time and input into the trained model, which then calculates its dynamic priority weights within milliseconds.

[0038] Furthermore, this application also includes the following steps: The specific steps for constructing the intelligent complementary decision-making model are as follows: obtaining a parking decision dataset, wherein the parking decision dataset is a sequence of historical events containing complementary operations and not containing complementary operations; identifying the input and output features of the parking decision dataset to obtain a decision input feature sample set and a decision output feature sample set; and using a long short-term memory network to train and update the decision input feature sample set and the decision output feature sample set to construct the intelligent complementary decision-making model.

[0039] Furthermore, this application also includes the following steps: the decision input feature sample set is a time-ordered sequence of events, each event includes its device type, event type, and data quality index, and the decision output feature sample set is a complementary decision instruction.

[0040] Specifically, the intelligent complementary decision-making model employs a long short-term memory network, which excels at processing time-series data and can understand the chronological order and contextual relationships of events. The decision input feature sample set is a time-ordered sequence of events, with each event containing its device type (entry, exit, occupancy, etc.) encoding and data quality indicators (such as confidence level and response time).

[0041] The decision output feature sample set is a complementary decision instruction, such as {action:PROCEED,reason:HIGH_CONFIDENCE_SEQUENCE}. The model is trained using a large number of historical event sequences that contain and do not contain complementary operations to learn in which event sequence patterns initiating complementarity is the optimal choice.

[0042] A large number of event sequences are extracted from historical logs. Each sequence is centered around a specific berth and covers a reasonable time window, such as from vehicle entry to exit, or a continuous 8-hour period. A key step is labeling each sequence: if the sequence automatically completes parking recording in actual operations without subsequent correction, it is labeled "Direct Processing"; if the sequence automatically initiates a query to another device during processing, it is labeled "Requires Confirmation from Device X"; if the record is ultimately closed only through manual reporting via PDA, it is labeled "Requires Manual On-Site Verification." Next is feature engineering, which transforms each event in the sequence into a feature vector. For example, an event is transformed into [Device Type Code = 2 (Video), Event Type Code = 1 (Entry), Confidence = 0.75]. Thus, a sequence containing 5 events becomes a 5x3 matrix. A Long Short-Term Memory (LSTM) network model is designed to handle these matrices. During the training phase, the model is fed thousands of such sequence matrices and their corresponding decision labels. It learns to recognize complex patterns through internal memory gates: for example, a pattern of low-confidence video entry → stable geomagnetic occupancy → prolonged absence of any exit signal is highly likely to correspond to an abandoned vehicle scenario, in which the optimal decision should be manual on-site verification. After the model is trained and deployed, when processing a new event in real time, the system uses that event as the endpoint and traces back the events of related berths over a period of time to form a real-time sequence, which is then input into the LSTM model. Within milliseconds, the model analyzes the context of the entire sequence and outputs a complementary decision instruction to guide the next action of the fusion engine.

[0043] S300: Build a multi-source flow fusion engine, and use the multi-source flow fusion engine to perform parking flow fusion analysis on the event data and attribute data of the multiple devices, as well as the adaptive learning module, to obtain parking flow processing data.

[0044] Furthermore, S300 of this application includes: the multi-source pipeline fusion engine specifically includes: an event standardization and preprocessing module, used to parse events from different sources, including timestamp unification, license plate number standardization, and data validity verification; an intelligent collaboration and complementary matching module, used to, when a new event is received, call the dynamic priority evaluation model to calculate a real-time dynamic weight for the event, call the intelligent complementary decision model, input the most recent event sequence, and determine whether to start the complementary process; a multi-level priority conflict resolution module, used to upgrade the decision logic when multiple candidate records are matched or conflicts occur, and follow the principle of high priority over low priority in decision-making; a special business processing module, used to intelligently process turnaround, inspection, and abandoned vehicle scenarios according to configured parameters; and a state machine manager, used to define the state for each parking record and ensure the atomicity of state transitions through distributed locks.

[0045] Furthermore, this application also includes the following steps: The principle of high priority over low priority is specifically as follows: First-level collaborative role priority:

[0046] MANUAL_AUDITOR>PRIMARY_VERIFIER>TRIGGER>STATUS_SENSOR; Second-level dynamic priority weight: within the same collaborative role, compare the dynamic weights calculated by the model, and decide the one with the higher weight; Third-level static individual priority: when the first two levels are the same, compare the static priority of the device.

[0047] Specifically, the multi-source pipeline fusion engine includes an event standardization and preprocessing module, an intelligent collaboration and complementary matching module, a multi-level priority conflict resolution module, and a special business processing module. The event standardization and preprocessing module acts as a cleaning and formatting workshop before data enters the core processing flow. It is responsible for processing the diverse event raw materials from the event bus into standardized semi-finished products for downstream modules. Through the event standardization and preprocessing module, events from different sources are parsed, and timestamps are standardized, license plate numbers are normalized, and data validity is verified, such as confidence level checks.

[0048] The intelligent collaboration and complementary matching module acts as the intelligent decision-making outpost of the multi-source pipeline fusion engine. It doesn't directly process records, but rather performs a pre-emptive check and prediction for each new event: assessing its individual strength (dynamic weight) and determining whether the current situation requires support (complementary decision). When a new event is received, the intelligent collaboration and complementary matching module invokes the dynamic priority evaluation model to calculate a real-time dynamic weight for the event; it then uses the intelligent complementary decision model, inputting the most recent event sequence, to determine whether a complementary process needs to be initiated. In other words, firstly, it invokes the dynamic priority evaluation model, inputting various characteristics of the event to obtain its dynamic weight (e.g., 0.85) within 5 milliseconds; secondly, it retrieves the most recent 30-minute event sequence for the berth from the cache, inputs it into the intelligent complementary decision model, and after analyzing the context within 10 milliseconds, returns a decision instruction, such as `action: PROCEED`, meaning that processing can continue without complementary intervention. At this point, the event has been assigned its individual strength value and action permission.

[0049] If a match is successful and there is no conflict, the update process begins. If multiple candidate records are matched or a direct conflict occurs, the multi-level priority conflict resolution module is activated. This module acts as the ultimate arbitration court. When data competition or contradictions arise, such as two events claiming to be the same vehicle's entry signal, it makes an irrefutable final ruling based on a hierarchical set of rules—the three-tier priority principle—to determine which event should be adopted to create or update the parking record. The first tier is the collaborative role priority: MANUAL_AUDITOR > PRIMARY_VERIFIER > TRIGGER > STATUS_SENSOR; the second tier is dynamic priority weight: within the same collaborative role, the dynamic weights calculated by the model are compared, with the higher weight prevailing; the third tier is static individual priority: only when the first two tiers are identical is the static priority of the device compared. The three-tier arbitration principle is strictly followed: first, the collaborative role of the event source is compared, with reports from human inspectors always having higher priority than automatic video recognition; if the roles are identical, dynamic weights are compared, with the one deemed more credible by the model prevailing; only when the first two are completely identical is the preset static device priority activated. This adjudication process is typically completed within 20 milliseconds.

[0050] For scenarios requiring the creation of new records or handling such as reversals after a ruling, such as the same license plate re-entering within 15 minutes, the special business processing module will intervene and apply specific business logic. This module handles non-standard cases and has built-in identification rules and processing logic for complex business scenarios, such as vehicles repeatedly entering and exiting within a short period, inspection and correction, and long-term parking, ensuring that even peripheral cases not covered by general processes are properly handled.

[0051] Regardless of the operation performed, the state machine manager intervenes, acquiring a unique lock on the target record at the database level. Then, within a single transaction, it atomically completes the state change and data write, ensuring that even with thousands of events processed per second, no two records will simultaneously update the same data. The state machine manager defines states such as INCOMPLETE, COMPLETE, PAID, and CLOSED for each parking record and ensures the atomicity of state transitions through distributed locks. The intelligent coordination and complementary matching module: When a new event is received, this module calls the dynamic priority evaluation model to calculate a real-time dynamic weight for the event; it then calls the intelligent complementary decision model, inputting the most recent event sequence to determine whether a complementary process needs to be initiated. After processing, a new parking record event is published to the bus, notifying downstream systems such as billing.

[0052] Through standardized preprocessing and rigorous state machine management, the raw, chaotic event stream is transformed flawlessly and without omission into highly complete and consistent parking records suitable for billing and operations. A three-tiered arbitration mechanism ensures that conflict resolution outcomes are business-appropriate, scenario-adaptable, and fundamentally deterministic, reducing the decision-making error rate in complex scenarios to below 1%.

[0053] S400: The data storage and business system is used to store and coordinate the event data published by the multiple devices and the parking flow processing data.

[0054] Specifically, a relational database such as PostgreSQL is used to store parking records, while a NoSQL database such as Elasticsearch is used to store event history for querying. Downstream business systems such as billing and apps collaborate by consuming new events published by the engine, such as ParkingRecordCreated. When the multi-source pipeline fusion engine completes a process, such as creating, updating, or closing a parking record, it triggers an atomic write transaction. In this transaction, the core parking record (including license plate number, parking space, precise entry and exit times, status, cumulative confidence weight, etc.) is written to the parking_records table in the relational database. At the same time, all original events related to this record and derivative events generated during engine processing (such as dynamic weight values, complementary decision instructions, conflict resolution logs, etc.) are written in batches to a specified index in Elasticsearch as an immutable audit trail. The index is appended with multi-dimensional tags such as record ID, timestamp, and device ID for subsequent millisecond-level retrieval. This hybrid storage strategy ensures strong consistency and transaction security for core business data while also meeting the needs for complex queries and analyses of massive event data, such as quickly querying all original identification records of a vehicle over the past month.

[0055] The system proactively notifies the outside world by publishing domain events. Immediately after successfully committing a database transaction, the state machine manager publishes a structured business event to the event bus. For example, when a record's state changes to COMPLETED, indicating a vehicle has exited, a ParkingRecordCompleted event is published. The event body contains key information such as record ID, license plate, entry time, exit time, and parking space. The billing system, as a subscriber to this event, receives it in real time, triggering the billing rule engine to calculate parking fees and generate a payment order. Simultaneously, the user application's backend service also subscribes to such events, immediately pushing exit notifications and payment information to the corresponding vehicle owner's mobile app. The entire notification process is asynchronous and decoupled; brief failures or processing delays in downstream systems will not block the continuous operation of the core pipeline processing engine. Furthermore, the operations management platform can obtain real-time statistical information, such as the current number of vehicles present, by directly querying the relational database. It can also build real-time data dashboards, generate daily operational reports, or perform deep data mining to optimize parking lot operation strategies by consuming the event bus or querying Elasticsearch.

[0056] In a specific example, a vehicle enters the parking lot at night on a rainy day. Due to the influence of light and raindrops, the high-view video has a low confidence level for identification. Through a dynamic priority model, the system can perceive the impact of environmental changes on equipment performance and intelligently reduce its weight. Simultaneously, a complementary decision model further ensures that when data quality is poor, it proactively seeks more reliable confirmation, achieving a leap from passive rules to proactive intelligence. The dynamic priority evaluation model is a pre-trained XGBoost model. At time T1, the high-view video publishes a VehicleEntryDetected event with a confidence_score of 0.75. At T1+0.5 seconds: the engine consumes this event, and the intelligent collaboration and complementary matching module calls the dynamic priority evaluation model.

[0057] The model receives input features:

[0058] {time:23:00,weather:rain,device_type:High-PositionVideo,recent_success_rate:0.92,current_confidence:0.75}. The model outputs a dynamic weight, such as 0.65. Because it's raining at night and the current confidence is low, the model automatically lowers the weight of this video event. Almost simultaneously, the geomagnetic field publishes a BerthOccupied event. The model might calculate a dynamic weight of 0.55 for it, as its role is STATUS_SENSOR, which has a lower base weight. When comparing, although the video event weight (0.65) is higher than the geomagnetic event weight (0.55), the intelligent complementary decision-making model might output a REQUIRE_COMPLEMENT instruction because the video confidence is below the threshold. The system pauses record creation and waits for the inspector's PDA confirmation.

[0059] The priority mechanism is dynamic, machine learning-based, and adaptive in real time, improving accuracy by 15% in complex environments and automatically adapting to changes in environment and equipment. Complementary decision-making, based on an LSTM model, understands the context of events, improving the recognition rate of abnormal scenarios by 30% and discovering complex problems that rules cannot cover. The system's intelligence adopts a learning model for proactive prediction and decision-making, reducing the need for manual intervention by 50% and possessing the ability to self-optimize and evolve. Special scenario handling adopts human-machine collaboration and automated processing, reducing the cost of manual intervention by 95%, and seamlessly integrating manual operations into the automated process, becoming the system's final insurance.

[0060] In summary, the parking flow management method based on multi-device collaborative management provided in this application has the following technical effects:

[0061] The system acquires multi-device event data and multi-device attribute data through an event publishing layer, which consists of all heterogeneous sensing devices. The multi-device attribute data includes device type, collaborative role, and data quality indicators. An adaptive learning module is constructed, comprising a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model uses a gradient boosting decision tree, and the intelligent complementary decision model uses a long short-term memory network. A multi-source flow fusion engine is built to perform parking flow fusion analysis on the multi-device event data, multi-device attribute data, and the adaptive learning module, yielding parking flow processing data. A data storage and business system is used to collaboratively store the multi-device event data and the parking flow processing data. In other words, by establishing a collaborative working model among devices, different types of devices can participate in the identification of parking events based on their respective expertise. An adaptive priority model based on machine learning and an intelligent fusion algorithm based on machine learning are designed. When resolving conflicts, the dynamic weights output by the model are used as the decision-making basis, making the decision more scientific and adaptive. Through a distributed state machine and recording all change events, data consistency and complete traceability under high concurrency are ensured, enabling the management of parking records in complex scenarios and improving the accuracy of parking flow data.

[0062] Example 2: Based on the same inventive concept as the parking flow management method based on multi-device collaborative management in Example 1, this application also provides a parking flow management system based on multi-device collaborative management. Please refer to the appendix. Figure 2 The parking flow management system based on multi-device collaborative management includes:

[0063] The data acquisition unit 11 is used to acquire multi-device published event data and multi-device attribute data through the event publishing layer, wherein the event publishing layer consists of all heterogeneous sensing devices, and the multi-device attribute data includes device type, collaborative role, and data quality indicators; the model building unit 12 is used to build an adaptive learning module, wherein the adaptive learning module includes a dynamic priority evaluation model and an intelligent complementary decision model, wherein the dynamic priority evaluation model adopts a gradient boosting decision tree, and the intelligent complementary decision model adopts a long short-term memory network; the parking flow fusion analysis unit 13 is used to build a multi-source flow fusion engine, and uses the multi-source flow fusion engine to perform parking flow fusion analysis on the multi-device published event data, multi-device attribute data, and the adaptive learning module to obtain parking flow processing data; the collaborative storage unit 14 is used to perform collaborative storage work on the multi-device published event data and the parking flow processing data using the data storage and business system.

[0064] Furthermore, the data acquisition unit 11 in the parking flow processing system based on multi-device collaborative management is also used for: the event publishing layer further includes: an event bus, which serves as the central nervous system of the system and is responsible for receiving, caching and distributing events.

[0065] Furthermore, the model building unit 12 in the parking lot flow treatment system based on multi-device collaborative management is also used for:

[0066] The specific steps for constructing a dynamic priority evaluation model are as follows: acquire historical parking records and standard event data; identify the input and output features of the historical parking records and standard event data to obtain an evaluation input feature sample set and an evaluation output feature sample set; and use a gradient boosting decision tree to train the evaluation input feature sample set and the evaluation output feature sample set offline and update them periodically to construct a dynamic priority evaluation model.

[0067] Furthermore, the model building unit 12 in the parking lot flow treatment system based on multi-device collaborative management is also used for:

[0068] The evaluation input feature sample set specifically includes: environmental features, equipment static features, equipment dynamic features, and event features, and the evaluation output feature sample set is a dynamic priority weight between 0.0 and 1.0.

[0069] Furthermore, the model building unit 12 in the parking lot flow treatment system based on multi-device collaborative management is also used for:

[0070] The specific steps for constructing an intelligent complementary decision-making model are as follows: 1) Obtain a parking decision dataset, which is a sequence of historical events containing complementary operations and those not containing complementary operations; 2) Identify the input and output features of the parking decision dataset to obtain a decision input feature sample set and a decision output feature sample set; 3) Use a long short-term memory network to train and update the decision input feature sample set and the decision output feature sample set to construct an intelligent complementary decision-making model.

[0071] Furthermore, the model building unit 12 in the parking lot flow treatment system based on multi-device collaborative management is also used for:

[0072] The decision input feature sample set is a time-ordered sequence of events, each event containing its device type, event type, and data quality index. The decision output feature sample set is a complementary decision instruction.

[0073] Furthermore, the parking flow fusion analysis unit 13 in the parking flow processing system based on multi-device collaborative management is also used for:

[0074] The multi-source pipeline fusion engine specifically includes: an event standardization and preprocessing module, used to parse events from different sources, including timestamp unification, license plate number standardization, and data validity verification; an intelligent collaboration and complementary matching module, used to, when a new event is received, call the dynamic priority evaluation model to calculate a real-time dynamic weight for the event, call the intelligent complementary decision model, input the most recent event sequence, and determine whether to start the complementary process; a multi-level priority conflict resolution module, used to escalate the decision logic when multiple candidate records are matched or conflicts occur, and follow the principle of high priority over low priority in decision-making; a special business processing module, used to intelligently handle turnaround, inspection, and abandoned vehicle scenarios according to configured parameters; and a state machine manager, used to define the state for each parking record and ensure the atomicity of state transitions through distributed locks.

[0075] Furthermore, the parking flow fusion analysis unit 13 in the parking flow processing system based on multi-device collaborative management is also used for:

[0076] The principle of high priority over low priority is as follows: First layer: collaborative role priority: MANUAL_AUDITOR > PRIMARY_VERIFIER > TRIGGER > STATUS_SENSOR; Second layer: dynamic priority weight: within the same collaborative role, compare the dynamic weights calculated by the model and decide the one with the higher weight; Third layer: static individual priority: when the first two layers are the same, compare the static priority of the device.

[0077] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The parking flow processing method and specific examples based on multi-device collaborative management in the foregoing embodiment one are also applicable to the parking flow processing system based on multi-device collaborative management in this embodiment. Through the foregoing detailed description of the parking flow processing method based on multi-device collaborative management, those skilled in the art can clearly understand the parking flow processing system based on multi-device collaborative management in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0078] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0079] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application also intends to include such modifications and variations.

Claims

1. A parking lot flow management method based on multi-device collaborative management, characterized in that, include: Multi-device event data and multi-device attribute data are obtained through the event publishing layer. The event publishing layer consists of all heterogeneous sensing devices, and the multi-device attribute data includes device type, collaborative role, and data quality indicators. An adaptive learning module is constructed, which includes a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model adopts a gradient boosting decision tree, and the intelligent complementary decision model adopts a long short-term memory network. A multi-source flow fusion engine is built, and the multi-source flow fusion engine is used to perform parking flow fusion analysis on the event data and attribute data of the multiple devices and the adaptive learning module to obtain parking flow processing data. The data storage and business system is used to store and coordinate the event data published by the multiple devices and the parking flow processing data.

2. The parking lot flow treatment method based on multi-device collaborative management as described in claim 1, characterized in that, The specific steps for constructing a dynamic priority evaluation model are as follows: Retrieve historical parking records and standard event data; Input and output feature identifiers are applied to the historical parking records and standard event data to obtain an evaluation input feature sample set and an evaluation output feature sample set. A gradient boosting decision tree is used to train the evaluation input feature sample set and the evaluation output feature sample set offline and update them periodically to construct a dynamic priority evaluation model.

3. The parking lot drainage method based on multi-device collaborative management as described in claim 2, characterized in that, The evaluation input feature sample set specifically includes: environmental features, equipment static features, equipment dynamic features, and event features, and the evaluation output feature sample set is a dynamic priority weight between 0.0 and 1.

0.

4. The parking lot drainage method based on multi-device collaborative management as described in claim 3, characterized in that, The specific steps for constructing an intelligent complementary decision-making model are as follows: Obtain a parking decision dataset, which is a sequence of historical events containing complementary operations and not containing complementary operations; The parking decision dataset is labeled with input and output features to obtain a decision input feature sample set and a decision output feature sample set; A long short-term memory network is used to train and update the decision input feature sample set and the decision output feature sample set to construct an intelligent complementary decision model.

5. The parking lot drainage method based on multi-device collaborative management as described in claim 4, characterized in that, The decision input feature sample set is a time-ordered sequence of events, each event containing its device type, event type, and data quality index. The decision output feature sample set is a complementary decision instruction.

6. The parking lot drainage method based on multi-device collaborative management as described in claim 1, characterized in that, The multi-source flow fusion engine specifically includes: The event standardization and preprocessing module is used to parse events from different sources, including timestamp unification, license plate number standardization, and data validity verification. The intelligent collaboration and complementary matching module is used to call the dynamic priority evaluation model to calculate a real-time dynamic weight for the event when a new event is received, and to call the intelligent complementary decision model, input the most recent event sequence, and determine whether the complementary process needs to be started. The multi-level priority conflict resolution module is used to escalate the decision logic when multiple candidate records are matched or conflicts occur, and to make decisions in accordance with the principle that higher priority overrides lower priority. A special business processing module is used to intelligently handle scenarios such as turnaround, inspection, and abandoned vehicles based on configured parameters; A state machine manager is used to define the state for each parking record and ensure the atomicity of state transitions through distributed locks.

7. The parking lot flow treatment method based on multi-device collaborative management as described in claim 6, characterized in that, The principle of higher priority over lower priority is as follows: First-tier collaborative role priority: MANUAL_AUDITOR>PRIMARY_VERIFIER>TRIGGER>STATUS_SENSOR; The second layer of dynamic priority weights: within the same collaborative role, the dynamic weights calculated by the model are compared, and the one with the higher decision weight is selected. Third-level static individual priority: When the first two levels are the same, compare the static priority of the devices.

8. The parking lot drainage method based on multi-device collaborative management as described in claim 1, characterized in that, The event publishing layer also includes an event bus, which serves as the central nervous system of the system and is responsible for receiving, caching, and distributing events.

9. A parking lot drainage system based on multi-device collaborative management, characterized in that, The steps for implementing the parking flow management method based on multi-device collaborative management as described in any one of claims 1 to 8, wherein the parking flow management system based on multi-device collaborative management comprises: The data acquisition unit is used to acquire multi-device published event data and multi-device attribute data through the event publishing layer. The event publishing layer is composed of all heterogeneous sensing devices, and the multi-device attribute data includes device type, collaborative role, and data quality indicators. The model building unit is used to build an adaptive learning module, which includes a dynamic priority evaluation model and an intelligent complementary decision model. The dynamic priority evaluation model adopts a gradient boosting decision tree, and the intelligent complementary decision model adopts a long short-term memory network. The parking flow fusion analysis unit is used to build a multi-source flow fusion engine. The multi-source flow fusion engine is used to perform parking flow fusion analysis on the event data and attribute data of the multiple devices and the adaptive learning module to obtain parking flow processing data. The collaborative storage unit is used to collaboratively store the event data published by the multiple devices and the parking flow processing data using the data storage and business system.

Images