A disaster control method and system for toll station cloud station and degraded service second-level switching, a terminal and a medium

Abstract

This invention discloses a disaster recovery control method, system, terminal, and medium for millisecond-level switching between a toll station cloud platform and a downgraded service. The method includes: simultaneously connecting a toll station lane controller to both a cloud platform transaction service and a plaza downgraded transaction service, and reporting the connectivity and operational status of these services in real time; when the cloud platform transaction service is detected to be unavailable or in an abnormal state, determining whether to switch the current operating mode to the plaza downgraded mode, and completing toll collection using the plaza downgraded transaction service after receiving a confirmation switch command; if the cloud platform transaction service is detected to be restored and stably available, determining whether to switch the current operating mode to the cloud platform service mode, and completing toll collection using the cloud platform transaction service after receiving a confirmation switch command. This invention, through the lane controller handling millisecond-level device driving and critical data caching, combined with a primary / backup strategy and a downgrade mechanism, can ensure business continuity under various fault scenarios.

Description

Technical Field

[0001] This invention relates to the field of transportation information engineering technology, and in particular to a disaster recovery control method, system, terminal, and medium for second-level switching between toll station cloud stations and degraded services. Background Technology

[0002] Currently, most highway toll stations still use a "one station, one server room" model: each station independently configures servers, storage, and networks. Toll collection, monitoring, and auditing functions are often decentralized into multiple independent systems, forming a "siloed" architecture. This leads to problems such as difficulty in sharing data and business processes, inconsistent versions, and low resource utilization. Consequently, toll station operations are highly dependent on local server rooms and manual management, requiring not only a large number of toll collection and maintenance personnel but also incurring high operational costs for equipment and electromechanical facilities inspection and repair. At the same time, existing toll station systems struggle to form a unified disaster recovery system across stations and road sections, resulting in insufficient business continuity and data security capabilities.

[0003] Therefore, existing technologies still have shortcomings. Summary of the Invention

[0004] To address the aforementioned deficiencies in existing technologies, this invention provides a disaster recovery control method, system, terminal, and medium for second-level switching between toll station cloud stations and degraded services. The technical solution adopted by this invention is as follows: In a first aspect, the present invention provides a multi-station integration system for toll stations based on cloud-edge collaboration, the method comprising: Based on the toll station lane controller, it simultaneously connects to the cloud station transaction service and the plaza downgrade transaction service, and reports the connection status and operation status of the cloud station transaction service and the plaza downgrade transaction service in real time; When the cloud station transaction service is detected to be unavailable or in an abnormal state, determine whether it is necessary to switch the current working mode to the plaza downgrade mode, and after receiving the confirmation switch instruction, use the plaza downgrade transaction service to complete the payment. If the cloud site transaction service is detected to have recovered and become stable and available, determine whether it is necessary to switch the current working mode to the cloud site service mode, and complete the billing using the cloud site transaction service after receiving the confirmation switch instruction.

[0005] In one implementation, the method further includes: After the system starts up, the cloud site transaction service will be used by default.

[0006] In one implementation, when the cloud station transaction service is detected to be unavailable or in an abnormal state, it is determined whether the current working mode needs to be switched to the plaza downgrade mode. Upon receiving a confirmation switch instruction, the plaza downgrade transaction service is used to complete the billing process, including: After confirming the switch to the plaza downgrade mode, the lane controller uniformly accesses and collects data from vehicle detectors, roadside units, license plate recognition devices, lane cameras, etc., generates transaction elements, and forwards them to the downgrade server in the plaza cabinet via the toll aggregation switch. After completing the necessary billing and verification locally through the downgraded server, the amount due and the corresponding processing instructions are sent back to the lane controller, and the toll display screen is driven to show the amount and information. After the toll collection is completed, the traffic lights and barrier gates will be activated to allow passage.

[0007] In one implementation, when the cloud station transaction service is detected to be unavailable or in an abnormal state, it is determined whether the current working mode needs to be switched to the plaza downgrade mode. After receiving a confirmation switch instruction, the plaza downgrade transaction service is used to complete the payment. This also includes: Transaction records, logs, and evidence are retained locally during the downgrade period.

[0008] In one implementation, the method further includes: A pre-built cloud-edge collaborative multi-station toll station system is constructed. The system includes: a device and operating system layer, a lane controller and edge computing layer, and a platform and toll collection service layer. The device and operating system layer consists of various electromechanical devices and their underlying drivers at the toll station, which is the foundation for system perception and execution. The lane controller and edge computing layer is the hub for device access and edge collaboration, including the lane controller and Docker containers deployed on the lane controller. The lane controller has a built-in edge computing subsystem. The platform and toll collection service layer includes: a hyper-converged edge cloud, a toll collection service system, a Meta unified management platform, and a remote monitoring and maintenance platform, which are used to realize centralized deployment of toll collection services, multi-station integration, and remote monitoring and maintenance.

[0009] In one implementation, the hyperconverged edge cloud integrates computing, storage, and virtualization capabilities in the form of an all-in-one machine, providing a unified operating environment for the primary charging system and the backup degraded charging system; The toll collection system includes a primary toll collection system and a backup degraded toll collection system. The primary toll collection system is deployed as a Web Server at the hyperconverged edge to provide cloud station transaction services and is responsible for fee calculation, transaction processing, and accounting management under normal conditions. The backup degraded toll collection system is an independent Web Server instance that shares some data with the primary toll collection system but is logically isolated. When cloud station anomalies or lane services are affected, it switches to the plaza degraded transaction service within seconds with the coordination of the lane controller to take over the necessary toll collection functions. The Meta Unified Management Platform serves as a unified operations management portal, aggregating lane data, equipment information, and operational statistics from various stations. It provides road companies with a unified operational view and decision support, and, combined with the resource monitoring of the hyperconverged edge cloud, enables centralized management of computing nodes, virtual machines, and application containers.

[0010] In one implementation, the method further includes: If the cloud site transaction service is detected to have recovered and become stable and available, and no confirmation of switchover is received, the existing working mode will be maintained and the service will be reassessed periodically.

[0011] Secondly, embodiments of the present invention also provide a disaster recovery control system for second-level switching between toll station cloud stations and degraded services, wherein the system is used to implement the steps of the disaster recovery control method for second-level switching between toll station cloud stations and degraded services as described in any of the above solutions, and the system includes: The connection and status reporting module is used to simultaneously connect to the cloud station transaction service and the plaza downgrade transaction service based on the toll station lane controller, and report the connection status and operation status of the cloud station transaction service and the plaza downgrade transaction service in real time. The Plaza Degradation Transaction Service Switching Module is used to determine whether to switch the current working mode to Plaza Degradation mode when the cloud station transaction service is detected to be unavailable or in an abnormal state, and to complete the billing using Plaza Degradation Transaction Service after receiving the confirmation switch instruction. The cloud site transaction service recovery module is used to determine whether to switch the current working mode to the cloud site service mode if the cloud site transaction service is detected to be restored and stable. After receiving the confirmation switch instruction, the module will use the cloud site transaction service to complete the billing.

[0012] Thirdly, embodiments of the present invention also provide a terminal, wherein the terminal includes a memory, a processor, and an entity extraction and processing program stored in the memory and executable on the processor. When the processor executes the entity extraction and processing program, it implements the steps of the disaster recovery control method for second-level switching between the toll station cloud station and the downgrade service in any of the above schemes.

[0013] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein an entity extraction processing program is stored on the computer-readable storage medium, and the entity extraction processing program implements the steps of the disaster recovery control method for second-level switching between the toll station cloud station and the downgrade service as described in any of the above schemes on the computer-readable storage medium.

[0014] Beneficial Effects: Compared with existing technologies, this invention provides a disaster recovery control method for second-level switching between toll station cloud and downgraded services. Firstly, the toll station lane controller simultaneously connects to both the cloud transaction service and the plaza downgraded transaction service, and reports the connectivity and operational status of these services in real time. When the cloud transaction service is detected to be unavailable or in an abnormal state, it determines whether to switch the current operating mode to the plaza downgraded mode. Upon receiving a confirmation switch command, the plaza downgraded transaction service is used to complete toll collection. If the cloud transaction service is detected to be restored and stably available, it determines whether to switch the current operating mode to the cloud service mode. Upon receiving a confirmation switch command, the cloud transaction service is used to complete toll collection.

[0015] This invention uses a lane controller to handle millisecond-level device driving and critical data caching, and combines a primary / backup strategy with a degradation mechanism to ensure business continuity in various failure scenarios. Attached Figure Description

[0016] Figure 1 The flowchart illustrates the specific application of the disaster recovery control method for second-level switching between toll station cloud sites and downgraded services provided in this embodiment of the invention.

[0017] Figure 2 This invention relates to a cloud-edge collaborative multi-station toll station integration system.

[0018] Figure 3 This is a schematic diagram of the equipment composition of the lane controller in the disaster recovery control method for second-level switching between toll station cloud station and downgrade service provided in an embodiment of the present invention.

[0019] Figure 4 This invention describes the toll collection process in the ETC lane of a standard toll station.

[0020] Figure 5 This invention describes the cloud-edge collaborative charging process for small stations and standard stations in a multi-station integration scenario.

[0021] Figure 6 This is a schematic diagram illustrating the switching process between cloud-based transaction services and plaza-based downgraded transaction services in this invention.

[0022] Figure 7 This is a schematic diagram illustrating the process of downgrading the charging service according to the present invention.

[0023] Figure 8 This is a schematic diagram of the disaster recovery control system for toll station cloud station and degradation service switching in seconds, provided in an embodiment of the present invention.

[0024] Figure 9 A schematic diagram of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0026] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0027] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0028] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, "first control information" and "second control information" are only used to distinguish different control information and do not limit their order.

[0029] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0030] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] In recent years, new-generation information technologies such as cloud computing, big data, the Internet of Things, mobile internet, and artificial intelligence have been rapidly integrated into the transportation industry. "Internet + transportation" has become an important tool for transformation and upgrading, and an independent, controllable, secure, and reliable information technology system has become a rigid requirement. Based on the principle of cloud-edge collaboration, this invention proposes a disaster recovery control method for second-level switching between toll station cloud stations and degraded services. This method is beneficial for ensuring business continuity and for forming a three-level disaster recovery system of cloud, edge, and terminal.

[0032] Based on the above embodiments, the present invention also provides a disaster recovery control method for second-level switching between toll station cloud stations and degraded services. In specific implementation, the disaster recovery control method for second-level switching between toll station cloud stations and degraded services in this embodiment can be applied to terminals, including intelligent product terminals such as computers. Specifically, for example... Figure 1As shown in the figure, the disaster recovery control method for the second-level switching between the toll station cloud station and the downgrade service in this embodiment includes the following steps: Step S100: Based on the toll station lane controller, simultaneously connect to the cloud station transaction service and the plaza downgrade transaction service, and report the connection status and operation status of the cloud station transaction service and the plaza downgrade transaction service in real time; Step S200: When the cloud station transaction service is detected to be unavailable or in an abnormal state, determine whether it is necessary to switch the current working mode to the plaza downgrade mode, and after receiving the confirmation switch instruction, use the plaza downgrade transaction service to complete the payment. Step S300: If the cloud station transaction service is detected to have recovered and become stable and available, determine whether it is necessary to switch the current working mode to the cloud station service mode, and after receiving the confirmation switch instruction, use the cloud station transaction service to complete the payment.

[0033] In this embodiment, a multi-station integration system for toll stations based on cloud-edge collaboration is first built, such as... Figure 2 As shown, the system includes: a device and operating system layer, a lane controller and edge computing layer, and a platform and toll collection service layer. The device and operating system layer consists of various electromechanical devices and their underlying drivers at the toll station, which is the foundation for system perception and execution. The lane controller and edge computing layer is the hub for device access and edge collaboration, including the lane controller and Docker containers deployed on the lane controller. The lane controller has a built-in edge computing subsystem. The platform and toll collection service layer includes: a hyper-converged edge cloud, a toll collection service system, a Meta unified management platform, and a remote monitoring and maintenance platform, which are used to realize centralized deployment of toll collection services, integration of multiple stations, and remote monitoring and maintenance.

[0034] This embodiment of the system is based on "cloud-edge collaboration": the provincial cloud platform deploys an edge node management system, the road segment-level hyper-converged edge cloud uniformly carries toll station business, and the lane-side HarmonyOS lane controller undertakes local control and intelligent terminal functions. Through the three-level collaboration of the provincial platform—central edge cloud—lane controller, an operating mode of "cloud-based unified management, edge aggregation, and lane autonomy" is formed. Specifically, the cloud is responsible for toll processing, billing, and centralized operation and maintenance; the edge cloud is responsible for centralized deployment of multi-station business and data aggregation; and the lane controller is responsible for millisecond-level device driving and critical data caching. Combined with a primary / backup strategy and degradation mechanism, the system can ensure business continuity under various failure scenarios.

[0035] In practical applications, this embodiment, considering traffic volume, existing electromechanical scale, and station location, divides toll stations into central stations (large stations) and small stations. A unified hyper-converged edge cloud platform is built at the central station to centrally deploy station-level transaction, station-level management, gantry services, and entrance overload control systems. Unified deployment and upgrades of nodes and applications are achieved through cloud-edge collaboration. Small stations only deploy HarmonyOS lane controllers, retaining necessary network access. This migrates toll collection, monitoring, and other services originally scattered across various station server rooms to a centralized edge cloud platform, eliminating the need for individual stations to configure complete servers and storage facilities, thus achieving lightweighting and simplification of electromechanical equipment.

[0036] This embodiment of the cloud-edge collaborative toll station multi-station integration system is divided into three layers: the equipment and operating system layer, the lane controller and edge computing layer, and the platform and toll collection business layer. These three layers are decoupled using standardized interfaces. Through a hierarchical upward transition from the "equipment layer → control / edge layer → platform layer," unified access to lane electromechanical equipment, edge intelligent control, and centralized cloud-based toll collection and remote operation and maintenance are achieved. Figure 2 As shown, the bottom layer consists of various electromechanical equipment distributed across toll stations and lanes; the middle layer comprises lane controllers that uniformly access these devices and perform real-time control and preliminary data processing locally; the top layer consists of a road segment-level hyper-converged edge cloud, a unified Meta management platform, and a remote monitoring and maintenance platform, enabling centralized deployment of toll collection services, integration of multiple stations, and remote monitoring and maintenance. This three-layer collaborative architecture allows for the "abstraction" of station-level data centers into logical sites within the edge cloud without altering the essential processes of lane operations, forming a new model of "multiple stations sharing one cloud, cloud-edge collaborative operation."

[0037] Specifically, the equipment and operating system layer in this embodiment consists of various electromechanical devices and their underlying drivers at the toll station, forming the foundation for system perception and execution. Typical devices include any one or more of the following: inductive loop detectors, voice prompts, barrier gates, ETC (Electronic Toll Collection), mobile payment devices, toll display screens, weighing equipment, CPC card readers / writers, vehicle-to-everything (V2X) roadside units, license plate recognition, and toll monitoring cameras. To reduce the access complexity caused by devices from multiple vendors and using multiple protocols, a driver layer is introduced within the lane controller to manage these devices uniformly. Various devices connect via interfaces such as GPIO, UART, wired network cards, and USB. The driver management system (SO) provides a unified API, shielding hardware differences and allowing upper-layer services to focus only on functions such as vehicle detection, image acquisition, barrier gate control, and voice announcements, without needing to concern themselves with specific device models and communication details. This design facilitates centralized selection and batch deployment after multiple stations are integrated, and also reserves space for future equipment replacement and upgrades, thus reducing life-cycle maintenance costs.

[0038] Furthermore, the lane controller and the edge computing layer are the hubs for device access and edge collaboration, including the lane controller and the Docker containers deployed on the lane controller. The lane controller incorporates an edge computing subsystem that uniformly abstracts the device status and attributes (such as online status, fault alerts, lane modes, etc.) through the "device model", and on this basis, carries the lane business logic. In terms of software architecture, the lane controller provides standard interfaces and Web configuration interfaces externally in the form of business plugins and HTTP Server. Operation and maintenance personnel can directly complete parameter configuration, device debugging, and local operation and maintenance through a browser, reducing the dependence on dedicated maintenance terminals, and can expand new services through plugins as needed. Specifically, as Figure 3 shown in, the device composition of the lane controller includes: sensing and acquisition devices, vehicle-road communication devices, transaction payment devices, information publishing devices, safety warning devices, and ticket printing devices. On the one hand, the lane controller in this embodiment provides rich on-site interfaces and can access various electromechanical devices such as lane antennas, fare displays, mobile payment terminals, vehicle detectors, license plate recognition devices, etc.; on the other hand, it provides standardized business interfaces externally through a unified software framework to achieve unified access and management of devices from different manufacturers on the same controller. The controller has built-in edge computing capabilities, supports device status collection and preprocessing, local discrimination of key events, and can perform quick linkage control on devices such as license plate recognition devices and fare displays.

[0039] To enhance scalability and resource isolation capabilities, Docker containers are deployed on the lane controller: the lane detection and control measurement image integrates device SDKs, protocol adaptation libraries, and driver mappings to achieve unified access and collaborative control of electromechanical devices from multiple manufacturers; the camera streaming service image is responsible for video collection and forwarding, providing data for cloud or local video analysis. The overall control and edge computing functions are mounted on the IOT-Edge platform, and through it, local data aggregation, rule calculation, and two-way communication with the cloud Huawei IOT-Edge platform are completed: on the one hand, the lane operation and device health information is sent up as needed for operation and maintenance and management analysis; on the other hand, it supports the unified configuration and control instructions sent down by the cloud to achieve unified policy control across stations and lanes.

[0040] In cloud-edge collaboration, the lane controller mainly plays three roles: (1) When the cloud station is normal, it is responsible for real-time device driving and data collection, and sends transaction and status information to the edge cloud toll collection system, and the cloud completes fare calculation, warehousing, and clearing; (2) When the edge cloud or cloud station fails, it cooperates with the local downgraded toll server to take over the core toll collection logic, relies on local caching and simplified rules to ensure passage, and realizes the second-level switching between the cloud station and the downgraded service; (3) When the communication link is unstable or interrupted for a short time, the transaction data is temporarily stored locally and resumed after the breakpoint is broken. The data is automatically retransmitted after the network is restored to ensure that the accounting data is complete and consistent.

[0041] This embodiment introduces an autonomous and controllable lane controller, which, while ensuring real-time control of electromechanical equipment, constructs a collaborative mechanism of "cloud-based coordination, edge-based centralization, and lane autonomy," providing key support for multi-station integrated transformation and second-level disaster recovery capabilities.

[0042] Furthermore, the platform and billing service layer is located at the top of the architecture and mainly consists of a hyperconverged edge cloud platform, a billing service system, a unified Meta management platform, and a remote monitoring and maintenance platform.

[0043] This embodiment's hyperconverged edge cloud integrates computing, storage, and virtualization capabilities in an all-in-one form, providing a unified operating environment for the primary toll collection system and the backup degraded toll collection system. The toll collection system includes a primary toll collection system and a backup degraded toll collection system. The primary toll collection system is deployed as a Web Server at the hyperconverged edge, providing cloud station transaction services and handling toll calculation, transaction processing, and accounting management under normal conditions. The backup degraded toll collection system, as an independent Web Server instance, shares some data with the primary toll collection system but is logically isolated. When cloud station anomalies or lane operations are detected, it switches to the plaza degraded transaction service within seconds, taking over necessary toll collection functions, in coordination with the lane controller. The Meta unified management platform, as a unified operation management portal, aggregates lane data, equipment information, and operational statistics from each station, providing the road company with a unified operational view and decision support. Combined with the hyperconverged edge cloud's resource monitoring, it enables centralized management of computing nodes, virtual machines, and application containers.

[0044] This embodiment deploys the primary toll collection system, the backup degraded toll collection system, operation and maintenance components, and some data services on a hyperconverged edge cloud. Only a small number of edge cloud nodes need to be built for a road segment to support the business of multiple toll stations, realizing the integration of multiple stations and resource pooling. This reduces the number of traditional data centers and servers, and provides a physical foundation for cross-station disaster recovery and takeover.

[0045] In practical application, after a vehicle enters the ETC lane at the toll station, the lane detector detects the vehicle's entry and triggers the lane toll collection process, while the passage indicator light turns red. Next, the lane controller drives the lane camera to collect image data; drives the license plate recognition device to recognize the license plate information; and reads the vehicle's electronic tag information through the vehicle-to-everything (V2X) roadside unit. The system first determines whether the vehicle is an ETC vehicle. If not, it switches to manual processing, completes manual toll collection, and issues a departure command after toll collection is completed. If it is an ETC vehicle, it checks whether the vehicle's electronic tag is normal. If not, it switches to manual processing, completes manual toll collection, and issues a departure command after toll collection is completed. If the vehicle's electronic tag is normal, it verifies the validity of the vehicle's electronic tag and ETC card. If the verification fails, it switches to manual processing, completes manual toll collection, and issues a departure command after toll collection is completed. If the verification passes, it displays the amount due on the toll display screen, completes toll collection, and issues a departure command after toll collection is completed.

[0046] Combination Figure 4 As shown, the control method of this embodiment includes the following steps in specific applications: Step 1: The vehicle enters the ETC lane of the toll station, triggering three operations simultaneously: Step 1.1: The ramp pre-transaction antenna establishes a chain with the OBU (On-Board Unit) and reads the OBU information; Step 1.2: The vehicle detector detects the vehicle entering, and the HarmonyOS lane controller wakes up the lane process; Step 1.3: The red traffic indicator light illuminates.

[0047] Step 2: After the HarmonyOS lane controller wakes up the lane process, it executes the following: vehicle camera captures images, and license plate recognition device recognizes license plates.

[0048] Step 3: Perform a judgment: Is it an ETC vehicle? Step 3.1: If the result is "No": Transfer to manual / ETC-MTC hybrid processing → Mobile payment intervention → Manual toll collection → Barrier gate opens to allow passage → Vehicle exits ETC lane; Step 3.2: If the result is "Yes": Proceed to the "Is OBU abnormal?" judgment step.

[0049] Step 4: Determine if the OBU is malfunctioning. Step 4.1: If the result is "Yes": The barrier gate is raised to allow passage → the toll display and voice prompt prompt the vehicle to pull over / manual processing → standard toll station edge cloud → the printer prints a receipt and uploads the record to the provincial transaction system → the vehicle exits the ETC lane; Step 4.2: If the result is "No": Proceed to the "Repeated transactions within 3 minutes?" judgment stage.

[0050] Step 5: Determine if there are duplicate transactions within 3 minutes. Step 5.1: If the result is "yes": Proceed directly to the judgment step of "Does the captured license plate match the OBU license plate?" Step 5.2: If the result is "No": Proceed to the "OBU and ETC card validity" judgment stage.

[0051] Step 6: Determine the validity of the OBU and ETC card: Step 6.1: If the result is "No": The barrier gate is raised to allow passage → the toll display and voice prompt prompt the vehicle to pull over / manual processing → standard toll station edge cloud → the printer prints a receipt and uploads the record to the provincial transaction system → the vehicle exits the ETC lane; Step 6.2: If the result is "yes": Proceed to the judgment step of "Does the captured license plate match the OBU license plate?"

[0052] Step 7: Determine if the captured license plate matches the OBU license plate: Step 7.1: If the result is "No": The toll display and voice prompt will prompt you to pull over / manual processing → Standard toll station edge cloud → Printer prints receipt record and uploads it to the provincial transaction system → Vehicle exits ETC lane; Step 7.2: If the result is "Yes": The toll display shows the toll amount → Transaction successful → The barrier gate opens to allow passage → The vehicle exits the ETC lane. Records of the transaction and special situation handling process can be uploaded to the standard toll station edge cloud / station-level system, and a receipt can be printed and kept if necessary.

[0053] In this embodiment, the electromechanical equipment controlled by the lane controller installed at the small station is consistent with that of the standard station. For example... Figure 5 As shown, after a vehicle enters the ETC lane of the small station, the lane controller collects toll-related information such as license plate / capture image and associates it with the monitoring video. It packages the "transaction data + image / video" and uploads it to the standard station cloud. After the cloud completes the reception and storage, the station-level toll system calculates the amount due, and the entrance overload control system verifies and audits it. It then generates a receipt containing the amount and processing instructions and sends it to the lane controller. The controller sends the amount to the toll display screen (which can be linked to control voice / traffic lights / barriers) to complete the deduction and release. The transaction result is then sent back to the cloud for archiving to form a closed loop.

[0054] In other implementations, this embodiment switches the toll collection system when cloud station anomalies or lane service disruptions are detected. The toll collection system includes a primary toll collection system and a backup degraded toll collection system. The primary toll collection system is deployed as a Web Server at the hyperconverged edge, providing cloud station transaction services and handling fee calculation, transaction processing, and accounting management under normal conditions. The backup degraded toll collection system, as an independent Web Server instance, shares some data with the primary toll collection system but is logically isolated. When cloud station anomalies or lane service disruptions are detected, it switches to the plaza degraded transaction service within seconds, taking over necessary toll collection functions, in coordination with the lane controller. Therefore, in practical applications, under normal circumstances, lanes default to using the cloud station transaction service (i.e., the primary toll collection system) without any switching operations.

[0055] In practical applications, such as Figure 6 As shown, when the cloud station transaction service is detected to be unavailable or in an abnormal state, inconsistent with the current working mode, the IOT master controller determines that a switch to the backup downgraded toll collection system is needed based on the principle of "prioritizing cloud stations," and displays a prompt on the toll collection interface: "Station-level transaction system unavailable, switch to plaza downgrade?" After the toll collector confirms, the system marks the current mode as "downgraded," and the IOT master controller sends a switch command to the lane controller. The field equipment switches to the backup downgraded toll collection system, starts the plaza downgraded transaction service, and the lane continues to collect tolls in downgraded mode. The system continuously monitors the status of the cloud station transaction service during downgraded operation. When the station-level service is detected to have recovered and become stably available, the IOT master controller pushes a prompt to the downgraded toll collection interface: "Cloud station transaction service has recovered, switch to cloud station transaction service?" After the toll collector confirms again, the system completes the switchback from plaza downgrade to cloud station service, updates the current mode and the status of each WebUI, and restores the normal cloud station workflow; if no confirmation is made immediately, the existing mode is maintained and periodically re-evaluated.

[0056] Furthermore, combined Figure 7As shown, downgraded toll collection can be triggered when the cloud is unreachable, the private network link is interrupted, or critical services are abnormal. On the lane side, the HarmonyOS lane controller continues to uniformly access and collect data from vehicle detectors, RSUs (Roadside Units, used to read vehicle electronic tag information), license plate recognition devices, lane cameras, etc., generating transaction elements. Lane services are switched and forwarded to the downgrade server in the plaza cabinet via the toll aggregation switch, and isolated and access-controlled by the toll network firewall. In case of main link failure, AR devices (wireless escape links) can be activated to ensure communication. After completing necessary billing and verification locally, the downgrade server sends the "amount due and processing instructions" back to the lane controller. The controller drives the toll display / voice prompt to display the amount and information, and coordinates with traffic lights and barriers to complete passage. During downgrade, transaction records, logs, and evidence are stored locally. After the link is restored, they are batch-transmitted back to the cloud for archiving and reconciliation via transmission equipment. Once consistency is confirmed, downgrade is exited and normal operation resumes.

[0057] Therefore, this invention addresses the needs of multi-station consolidation and second-level disaster recovery at highway toll stations by constructing a hyper-converged edge cloud system combined with lane controllers. The system centrally hosts station-level services on the edge cloud, provides unified access to electromechanical equipment via lane controllers, and deploys degraded toll collection servers in the plazas of large and small toll stations, enabling centralized deployment of station-level services and rapid switching between cloud-based transaction services and plaza-based degraded services. Experimental results show that the system meets design goals in terms of data consistency, service availability, and switching latency, significantly reducing the size of data centers and servers compared to traditional models, and significantly improving cross-site disaster recovery capabilities. Further development can add more edge intelligent applications to the existing architecture, further promoting the digital and intelligent upgrade of highway toll collection systems.

[0058] Based on the above embodiments, the present invention also provides a disaster recovery control system for second-level switching between toll station cloud stations and degraded services. The system is used to implement the steps in the above method embodiments, such as... Figure 8 As shown in the diagram. The system in this embodiment includes: a connection and status reporting module 10, a plaza downgraded transaction service switching module 20, and a cloud station transaction service recovery module 30. Specifically, the connection and status reporting module 10 is used to simultaneously connect to the cloud station transaction service and the plaza downgraded transaction service based on the toll station lane controller, and report the connectivity and operational status of the cloud station transaction service and the plaza downgraded transaction service in real time. The plaza downgraded transaction service switching module 20 is used to determine whether to switch the current working mode to the plaza downgraded mode when the cloud station transaction service is detected to be unavailable or in an abnormal state, and to complete the toll collection using the plaza downgraded transaction service after receiving a confirmation switching instruction. The cloud station transaction service recovery module 30 is used to determine whether to switch the current working mode to the cloud station service mode if the cloud station transaction service is detected to be restored and stably available, and to complete the toll collection using the cloud station transaction service after receiving a confirmation switching instruction.

[0059] Based on the above embodiments, the present invention also provides a terminal, the principle block diagram of which can be as follows: Figure 9 As shown. The terminal may include one or more processors 100 ( Figure 9 (Only one is shown in the image), memory 101, and computer program 102 stored in memory 101 and executable on one or more processors 100. For example, an entity extraction processing program. When one or more processors 100 execute computer program 102, they can implement the various steps in the disaster recovery control method embodiment for second-level switching between toll station cloud station and degraded service. Alternatively, when one or more processors 100 execute computer program 102, they can implement the functions of various modules / units in the disaster recovery control system embodiment for second-level switching between toll station cloud station and degraded service, which is not limited here.

[0060] In one embodiment, the processor 100 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0061] In one embodiment, memory 101 may be an internal storage unit of an electronic device, such as a hard drive or RAM. Memory 101 may also be an external storage device of the electronic device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital Card (SD), or Flash Card. Furthermore, memory 101 may include both internal and external storage units. Memory 101 is used to store computer programs and other programs and data required by the terminal. Memory 101 can also be used to temporarily store data that has been output or will be output.

[0062] Those skilled in the art will understand that Figure 9The block diagram shown is merely a partial structural diagram related to the present invention and does not constitute a limitation on the terminal to which the present invention is applied. A specific terminal may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0063] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), direct memory bus RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0064] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A disaster recovery control method for second-level switching between toll station cloud sites and degraded services, characterized in that, The method includes: Based on the toll station lane controller, it simultaneously connects to the cloud station transaction service and the plaza downgrade transaction service, and reports the connection status and operation status of the cloud station transaction service and the plaza downgrade transaction service in real time; When the cloud station transaction service is detected to be unavailable or in an abnormal state, determine whether it is necessary to switch the current working mode to the plaza downgrade mode, and after receiving the confirmation switch instruction, use the plaza downgrade transaction service to complete the payment. If the cloud site transaction service is detected to have recovered and become stable and available, determine whether it is necessary to switch the current working mode to the cloud site service mode, and complete the billing using the cloud site transaction service after receiving the confirmation switch instruction.

2. The disaster recovery control method for second-level switching between toll station cloud station and downgraded service as described in claim 1, characterized in that, The method further includes: After the system starts up, the cloud site transaction service will be used by default.

3. The disaster recovery control method for second-level switching between toll station cloud station and downgraded service as described in claim 1, characterized in that, When cloud station transaction services are detected to be unavailable or in an abnormal state, determine whether it is necessary to switch the current working mode to the plaza downgrade mode. After receiving confirmation of the switch, use the plaza downgrade transaction service to complete the billing process, including: After confirming the switch to the plaza downgrade mode, the lane controller uniformly accesses and collects data from vehicle detectors, roadside units, license plate recognition devices, lane cameras, etc., generates transaction elements, and forwards them to the downgrade server in the plaza cabinet via the toll aggregation switch. After completing the necessary billing and verification locally through the downgraded server, the amount due and the corresponding processing instructions are sent back to the lane controller, and the toll display screen is driven to show the amount and information. After the toll collection is completed, the traffic lights and barrier gates will be activated to allow passage.

4. The disaster recovery control method for second-level switching between toll station cloud station and downgraded service as described in claim 1, characterized in that, When the cloud station transaction service is detected to be unavailable or in an abnormal state, determine whether it is necessary to switch the current working mode to the plaza downgrade mode. After receiving a confirmation switch instruction, complete the billing using the plaza downgrade transaction service, which also includes: Transaction records, logs, and evidence are retained locally during the downgrade period.

5. The disaster recovery control method for second-level switching between toll station cloud station and downgraded service as described in claim 1, characterized in that, The method further includes: A pre-built cloud-edge collaborative multi-station toll station system is constructed. The system includes: a device and operating system layer, a lane controller and edge computing layer, and a platform and toll collection service layer. The device and operating system layer consists of various electromechanical devices and their underlying drivers at the toll station, which is the foundation for system perception and execution. The lane controller and edge computing layer is the hub for device access and edge collaboration, including the lane controller and Docker containers deployed on the lane controller. The lane controller has a built-in edge computing subsystem. The platform and toll collection service layer includes: a hyper-converged edge cloud, a toll collection service system, a Meta unified management platform, and a remote monitoring and maintenance platform, which are used to realize centralized deployment of toll collection services, multi-station integration, and remote monitoring and maintenance.

6. The disaster recovery control method for second-level switching between toll station cloud station and downgraded service as described in claim 5, characterized in that, The hyperconverged edge cloud integrates computing, storage, and virtualization capabilities in the form of an all-in-one machine, providing a unified operating environment for the primary charging system and the backup degraded charging system; The toll collection system includes a primary toll collection system and a backup degraded toll collection system. The primary toll collection system is deployed as a WebServer at the hyperconverged edge to provide cloud station transaction services and is responsible for toll calculation, transaction processing, and accounting management under normal conditions. The backup degraded toll collection system is an independent Web Server instance that shares some data with the primary toll collection system but is logically isolated. When cloud station anomalies or lane services are affected, it switches to the plaza degraded transaction service within seconds with the coordination of the lane controller to take over the necessary toll collection functions. The Meta Unified Management Platform serves as a unified operations management portal, aggregating lane data, equipment information, and operational statistics from various stations. It provides road companies with a unified operational view and decision support, and, combined with the resource monitoring of the hyperconverged edge cloud, enables centralized management of computing nodes, virtual machines, and application containers.

7. The disaster recovery control method for second-level switching between toll station cloud station and downgrade service as described in claim 1, characterized in that, The method further includes: If the cloud site transaction service is detected to have recovered and become stable and available, and no confirmation of switchover is received, the existing working mode will be maintained and the service will be reassessed periodically.

8. A disaster recovery control system for toll station cloud stations and degradation services with second-level switching, characterized in that, The system is used to implement the disaster recovery control method for second-level switching between toll station cloud station and degradation service as described in any one of claims 1-7, and the system includes: The connection and status reporting module is used to simultaneously connect to the cloud station transaction service and the plaza downgrade transaction service based on the toll station lane controller, and report the connection status and operation status of the cloud station transaction service and the plaza downgrade transaction service in real time. The Plaza Degradation Transaction Service Switching Module is used to determine whether to switch the current working mode to Plaza Degradation mode when the cloud station transaction service is detected to be unavailable or in an abnormal state, and to complete the billing using Plaza Degradation Transaction Service after receiving the confirmation switch instruction. The cloud site transaction service recovery module is used to determine whether to switch the current working mode to the cloud site service mode if the cloud site transaction service is detected to be restored and stable. After receiving the confirmation switch instruction, the module will use the cloud site transaction service to complete the billing.

9. A terminal, characterized in that, The terminal includes a memory, a processor, and a disaster recovery control program for second-level switching between the toll station cloud station and the downgraded service, which is stored in the memory and can run on the processor. When the processor executes the disaster recovery control program for second-level switching between the toll station cloud station and the downgraded service, it implements the steps of the disaster recovery control method for second-level switching between the toll station cloud station and the downgraded service as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a disaster recovery control program for second-level switching between the toll station cloud station and the degraded service. The disaster recovery control program for second-level switching between the toll station cloud station and the degraded service implements the steps of the disaster recovery control method for second-level switching between the toll station cloud station and the degraded service as described in any one of claims 1-7 on the computer-readable storage medium.

Images