Toll collection system

Abstract

To provide a toll collection system with enhanced operational continuity at low cost.SOLUTION: A toll collection system of an embodiment includes a plurality of tollgate apparatuses that collect road use information of a vehicle using a toll road. The toll collection system further includes an operating system, a standby system, and a remote server. The operating system is built on-premise at a main site, which is different from an installation location of the tollgate apparatus, and includes a control function that communicates with the plurality of tollgate apparatuses to control the plurality of tollgate apparatuses. The standby system is built on a cloud as a standby system for the operating system. The remote server remotely switches and operates the operating system and the standby system.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present invention relates to a toll collection system. [Background technology]

[0002] ETC (Electronic Toll Collection System) is already widely used on toll roads and other roads. This type of toll collection system is operated by road operators and is required to be highly reliable. In particular, in recent years, there has been an increase in the occurrence of heavy rain and landslide disasters, and there is concern that ETC sites and other facilities may be affected. In light of this, there has been an increased awareness of the need to build so-called disaster recovery sites for toll collection systems as well. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2011-150459 A [Patent Document 2] JP 2017-112631 A [Patent Document 3] JP 2018-55518 A [Patent Document 4] JP 2001-243587 A Summary of the Invention [Problem to be solved by the invention]

[0004] Disaster recovery sites can be considered as a backup for the main site that is operated under normal circumstances, and are attracting attention as a means of ensuring the continuity of system operations and business continuity. However, building a disaster recovery site for a toll collection system has been difficult due to various difficulties in terms of cost and operation. This is particularly a heavy burden for relatively small operating entities. Some kind of technological innovation is required from the perspective of ensuring operational continuity. Therefore, the objective is to provide a toll collection system with improved operational continuity at low cost. [Means for solving the problem]

[0005] The toll collection system of the embodiment is a toll collection system equipped with a plurality of toll gate devices that collects road usage information of vehicles using toll roads. The toll collection system further includes an operational system, a standby system, and a remote server. The operational system is constructed on-premise at a main site different from the installation location of the toll gate devices, and has a control function of communicating with the plurality of toll gate devices and controlling the plurality of toll gate devices. The standby system is constructed on the cloud as a standby system for the operational system. The remote server remotely switches between the operational system and the standby system. [Brief description of the drawings]

[0006] [Figure 1] FIG. 1 is a system diagram showing an example of a fee collection system according to an embodiment. [Diagram 2] FIG. 2 is a functional block diagram illustrating an example of the remote server 200 shown in FIG. [Diagram 3] FIG. 3 is a sequence diagram showing an example of a processing procedure executed in the fee collection system according to the embodiment. [Figure 4] FIG. 4 is a schematic diagram showing an example of operation in the fee collection system according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Hereinafter, an embodiment will be described with reference to the drawings.

[0008] 1 is a system diagram showing an example of a toll collection system according to an embodiment. This system includes a plurality of toll booth devices 11-1n, a remote server 200, and a main site 300, which are communicatively connected to each other via a network 100. Furthermore, the toll booth devices 11-1n, the remote server 200, and the main site 300 can use various resources and services of a cloud 400 via the network 100. In particular, the network 100 includes communication nodes 21-2n. The toll booth devices 11-1n can be connected to the communication nodes 21-2n, respectively, via wireless communication links.

[0009] 1, toll booth devices 11-1n are installed in areas managed by road operators, such as entrances, exits, or checkpoints of toll roads. The toll booth devices 11-1n are connected to gantries G through which vehicles using the toll roads pass, and acquire road usage information of vehicles that have passed through the gantry G. The road usage information is transmitted to a main site 300 via wireless communication links, communication nodes 21-2n, and a network 100.

[0010] The main site 300 is installed at a location different from the locations where the tollgate devices 11 to 1n are installed, such as an office of a road operator. The main site 300 includes an operational system 301 having an operational database 302.

[0011] The operational system 301 is constructed on-premise at the main site 300, and communicates with the toll gate devices 11-1n via the network 100 to control the toll gate devices 11-1n. This function is called a control function. The operational system 301 stores road usage information collected from the toll gate devices 11-1n in the operational database 302 (road usage information 303).

[0012] Meanwhile, in the embodiment, the cloud 400 includes a standby system 401. The standby system 401 is constructed on the cloud 400 as a standby system for the operational system 301. Here, the standby system 401 may be, for example, a virtual server formed on an actual computer by virtualization technology. The standby system 401 includes a standby database 402. The standby database 402 is synchronized with the operational database 302 and stores road usage information 403. The remote server 200 switches between the operational system 301 and the standby system 401 remotely via the network 100. The remote server 200 is installed in a location relatively far away from the toll gate devices 11-1n and the main site 300. For example, if the toll gate devices 11-1n and the main site 300 are installed in the same prefecture, it is assumed that the remote server 200 is installed in a different prefecture. In other words, it is preferable that the remote server 200 is geographically separated to such an extent that it will not go down due to the same disaster, such as heavy rain or landslide, even if the toll gate devices 11-1n and the main site 300 are affected by the same disaster.

[0013] 2 is a functional block diagram showing an example of the remote server 200. The remote server 200 is a computer including a read only memory (ROM) 220, a random access memory (RAM) 230, a storage unit 240, and a processor 250.

[0014] The storage unit 240 is a non-volatile storage such as a hard disk drive (HDD) or a solid state drive (SSD), and stores a program 240a executed by the processor 250.

[0015] The ROM 220 stores basic programs such as a Basic Input Output System (BIOS) and a Unified Extensible Firmware Interface (UEFI), various setting data, etc. The RAM 230 temporarily stores programs and data loaded from the storage unit 240.

[0016] The remote server 200 further includes an optical media drive 260 and a communication unit 270 . The optical media drive 260 reads digital data recorded on a recording medium such as a CD-ROM 280. Various programs executed by the remote server 200 are recorded on, for example, a CD-ROM 280 and distributed. The programs stored on the CD-ROM 280 are read by the optical media drive 260 and installed in the storage unit 240.

[0017] The communication unit 270 has a communication function and controls communication with the network 100. Various programs executed in the remote server 200 can be downloaded from a server via the communication unit 270, for example, and installed in the storage unit 240. The latest programs can also be downloaded from the cloud 400 via the communication unit 270, and installed programs can be updated.

[0018] The processor 250 executes an OS (Operating System) and various programs. The processor 250 also includes a synchronization processing unit 250a, a fault detection unit 250b, and a switching processing unit 250c as processing functions according to the embodiment. The synchronization processing unit 250a, the fault detection unit 250b, and the switching processing unit 250c can be understood as a process generated by loading the program 240a stored in the storage unit 240 into the RAM 230 and having the processor 250 execute arithmetic processing as the program progresses. That is, the program 240a causes the remote server 200, which is a computer, to function as the synchronization processing unit 250a, the fault detection unit 250b, and the switching processing unit 250c.

[0019] The synchronization processing unit 250a periodically or irregularly transmits a data synchronization request command to the operational system 301 (or the standby system 401) and synchronizes the standby database 402 with the operational database 302. As a result, the road usage information 303 stored in the operational database 302 and the road usage information 403 stored in the standby database 402 are synchronized. The fault detection unit 250b monitors the communication state between the toll gate devices 11-1n and the operational system 301. When a communication fault between at least one of the toll gate devices 11-1n and the operational system 301 is detected, the fault detection unit 250b notifies the switching processing unit 250c of the failure. When communication between the toll gate device and the operational system 301 that was not able to communicate is restored, the fault detection unit 250b detects recovery from the communication fault and notifies the switching processing unit 250c of the failure.

[0020] When the above communication failure is detected, the switching processing unit 250c performs control to have the standby system 401 take over the control function of the active system 301. When the recovery of communication is detected, the switching processing unit 250c performs control to switch back the control function of the standby system 401 to the active system 301. That is, when the switching processing unit 250c is notified of the occurrence of a communication failure by the failure detection unit 250b, it issues a switching request command to the active system 301 (or the standby system 401). When the switching processing unit 250c is notified of the recovery of the communication failure by the failure detection unit 250b, it issues a switchback request command to the standby system 401 (or the active system 301).

[0021] Next, the operation of the above configuration will be described. Fig. 3 is a sequence diagram showing an example of a processing procedure executed in the toll collection system according to the embodiment. In Fig. 3, it is assumed that the operational system 301 is in an operational state (step S1), and the standby system 401 is in a standby state (step S2). From this state, the remote server 200 transmits a synchronization request command to the operational system 301 (step S3). In response to this, the operational system 301 performs a synchronization process to synchronize data in each database with the standby system 401 (step S4).

[0022] As a result, the data stored in the standby database 402 is always synchronized with the data stored in the operational database 302. Also, the standby system 401 can start operating immediately after the system switchover, and the vehicle road usage information collected by the operational system 301 can be protected.

[0023] From this state, suppose that a failure occurs due to a heavy rain disaster or the like, and that failure is detected by the remote server 200 (step S5). In response, the remote server 200 transmits a switch request command to the operational system 301 (step S6). Receiving this, the operational system 301 performs a handover process with the standby system 401 (step S7).

[0024] The takeover process includes, for example, notification of the identifiers and communication addresses of remaining toll booth devices that have not been affected by the disaster, and transmission of previously buffered road usage information (for which synchronization has not yet been completed).

[0025] When the handover is completed, the operational system 301 goes into a standby state (step S8), and the standby system 401 of the cloud 400 goes into an operational state (step S9). The standby system 401 that has started operation collects road usage information from the remaining toll booth devices (step S10) and stores it in the standby database 402.

[0026] From this state, it is assumed that the disaster is restored and the restoration from the failure is detected by remote server 200 (step S11). Then, remote server 200 transmits a switchback request command to standby system 401 (step S12). Receiving this, standby system 401 performs a switchback process with operational system 301 (step S13).

[0027] The switchback process includes, for example, a process of transmitting road usage information collected by the standby system 401 during the duration of the failure and accumulated in the standby database 402 to the active database 302 .

[0028] Then, when the switchback process is completed, the active system 301 returns to the active state (step S14), and the standby system 401 goes back to the standby state (step S15). The above process procedure is repeated while the system is in operation.

[0029] Fig. 4 is a schematic diagram showing an example of operation of the toll collection system according to the embodiment. In Fig. 4, a case is assumed in which the main site is damaged in a disaster, and some of the toll gate devices are also damaged, but some toll gate devices are spared from damage. As shown in Fig. 4, data from the on-premise main site 300 is lifted up to the cloud 400, and the data stored in each database of the main site 300 and the cloud 400 is always synchronized. This makes it possible to protect various data, including road usage information, collected at the main site 300 from disasters.

[0030] In this state, if the main site 300 or any of the toll gate devices 11 to 1n is damaged and cannot communicate, the control function is taken over by the cloud 400 through remote control from the remote server 200. This allows the operation of the toll collection system to continue.

[0031] With existing technology, all toll collection systems of road operators are built on-premise, and availability against equipment failure is ensured by redundancy of equipment and components. As a countermeasure against disasters such as fires and earthquakes, operation continuity is ensured by preparing a separate site (disaster recovery site) on-premise from the site where normal operations are carried out (main site). However, it has been difficult for small road operators, in particular, to introduce a physical disaster recovery site mainly for the following reasons:

[0032] (1) Disaster recovery sites require the preparation of facilities and equipment that are not used in normal operations, and require daily system maintenance. This places a heavy financial and management burden on small road operators, making it difficult for them to respond.

[0033] (2) Small-scale road operators manage small areas, and the site where normal operations are carried out (main site) and the disaster recovery site can only be located geographically close to each other. Therefore, when the main site is affected by a disaster, the disaster recovery site is also affected, making it difficult to continue operations and raising the risk of data loss.

[0034] (3) If a system problem occurs during a disaster, recovery will take a long time because the distance between the disaster recovery site and the maintenance manufacturer's base is long and it takes time for the system to reach the site.

[0035] In response to this, in the embodiment, a function similar to the toll collection function implemented in the on-premise system is provided on the cloud, so that the operation of the entire toll collection system can be continued. As a result, the remaining undamaged control target systems can be continuously operated by control from the cloud. In addition, data of the on-premise system can be protected on the cloud. In addition, the toll collection system can be operated and maintained from a remote location, and the damage situation can be confirmed. Furthermore, when the facility is restored, data can be returned to the on-premise side by control from the remote server 200. That is, according to the embodiment, the following effects are obtained as advantages mainly in terms of operation. - Systems that are subject to control and are not affected (such as toll booth equipment) can continue to operate. - Capable of restoring operations even if the main site is damaged. -Road usage information related to toll collection will be protected.

[0036] In addition, the main cost advantages are as follows: - Since there is no need to build facilities or acquire land, the cost and time required to build a disaster recovery site is significantly reduced. - The cost of securing maintenance personnel for the disaster recovery site and running costs such as electricity bills can be significantly reduced compared to operating a physical site.

[0037] For these reasons, according to the embodiment, it is possible to provide a toll collection system with improved operational continuity at low cost.

[0038] Although the embodiment has been described, this embodiment is presented as an example and is not intended to limit the scope of the invention. This novel embodiment can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. This embodiment and its modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0039] 11-1n...toll booth device, 21-2n...communication node, 100...network, 200...remote server, 220...ROM, 230...RAM, 240...memory unit, 240a...program, 250...processor, 250a...synchronization processing unit, 250b...fault detection unit, 250c...switching processing unit, 260...optical media drive, 270...communication unit, 300...main site, 301...operation system, 302...operation database, 303...road usage information, 400...cloud, 401...standby system, 402...standby database, 403...road usage information.

Claims

1. A plurality of toll booth devices that collect road usage information of vehicles using a toll road; an operation system that is constructed on-premise at a main site different from the installation location of the toll gate device, has an operation system database that communicates with the plurality of toll gate devices and stores the collected road usage information, and controls the plurality of toll gate devices; a standby system constructed on a cloud as a standby system for the operational system, the standby system including a standby database for storing the road usage information collected by the toll booth device; a remote server that remotely switches between the operational system and the standby system; The remote server comprises: a synchronization processor that synchronizes the standby database with the operational database; A failure detection unit that detects a communication failure between at least one toll booth device and the operational system; A toll collection system comprising: a switching control unit that, when a communication failure is detected by the failure detection unit, causes the operational system to execute a handover process including notifying the standby system of the identifiers and communication addresses of the remaining toll booth devices and transmitting road usage information for which synchronization has not been completed to the standby system, thereby causing the standby system to take over the control functions of the operational system.

2. The standby system is installed in a location geographically distant from the location of the operational system so that the standby system will not go down due to the same disaster. The toll collection system according to claim 1.

3. The synchronization processing unit transmits a synchronization request command to the operational system when the operational system is in an operational state and the standby system is in a standby state, and the operational system, upon receiving the command, performs a synchronization process to synchronize data in each database with the standby system. The toll collection system according to claim 1.

4. The failure detection unit detects recovery from the communication failure, the switching control unit switches the control function of the standby system back to the operational system when the recovery is detected. The toll collection system according to claim 1.

5. the plurality of toll booth devices communicate with the standby system via wireless communication links; The toll collection system according to claim 1.

Images