Fail recovery method and internet of things system and charging system using the same

This application claims the priority benefits of U.S. provisional application Ser. No. 62/210,421, filed on Aug. 26, 2015 and Taiwan application serial no. 105122779, filed on Jul. 19, 2016. The entirety of each of the above-mentioned patent applications is hereby incorporated by reference herein and made a part of this specification.

1. Field of the Invention

The invention relates to a wireless communication technique, and more particularly, to a fail recovery method and an Internet of Things system and a charging system using the same.

2. Description of Related Art

The concept of Internet of Things (IoT) was first proposed in year 1999. The concept mentioned an approach of connecting to the Internet in a wireless manner with use of radio frequency identification (RFID), infrared ray, global positioning system (GPS), laser scan and other information sensing devices. Information may be exchanged, communicated, smartly verified, positioned, tracked, monitored and managed to further extend the reach of obtaining and managing information to perception layer thereby achieving a broader interoperability.

IoT devices from various manufacturers may use different interfaces for connection and may adopt different protocols for communication. Therefore, a gateway device is usually required in an IoT system as a mechanism for controlling and conversion between the protocols so the IoT devices with different specifications can communicate with each other.

As such, it can be known that the gateway device plays an important role in the IoT system. In the business environment that operates 24 hours a day, 7 days a week, once the gateway device is failed, the IoT devices are unable to communicate with each other or be controlled, resulting in service interruption on the entire business, which may lead to a great loss in terms of business operation. Accordingly, it has become very important as how to develop a fault tolerance mechanism so the gateway device can recover from a failure rapidly in order to provide service continuously without being interrupted.

The invention is directed to a fail recovery method and an IoT system and a charging system using the same, which are capable of solving the problem mentioned in Description of Related Art.

The fail recovery method of the IoT system of the invention includes following steps: providing a plurality of gateway devices, in which at least one of the gateway devices preset to provide a wireless network service to at least one IoT device and at least another one of the gateway devices preset to provide the wireless network service to at least one user device; mutual confirming an operation state of the other one of the gateway devices by the gateway devices; and when the one of the gateway devices is determined as failed, using the another one of the gateway devices to replace the failed gateway device, so as to simultaneously provide the wireless network service to the IoT device and the user device by the another one of the gateway devices.

The IoT system of the invention includes a plurality of gateway devices. At least one of the gateway devices preset to provide a wireless network service to at least one IoT device and at least another one of the gateway devices preset to provide the wireless network service to at least one user device. The gateway devices mutual confirm an operation state of the other one of gateway devices. When the one of the gateway devices is determined as failed, the another one of the gateway devices replaces the failed gateway device to simultaneously provide the wireless network service to the IoT device and the user device.

The charging system based on IoT of the invention includes at least one charging device, a plurality of gateway devices and a data center. The charging device is adapted to charge at least one user device, At least one of the gateway devices preset to provide a wireless network service to the charging device, and at least another one of the gateway devices preset to provide the wireless network service to the user device. The data center is adapted to communicate with the gateway devices, and configured to store data messages of the charging device and the user device. The gateway devices mutual confirm an operation state of the other one of gateway devices. When one of the gateway devices is determined as failed, another one of the gateway devices replaces the failed gateway device to simultaneously provide the wireless network service to the charging device and the user device.

Based on the above, the fail recovery method and the IoT system and the charging system using the same are proposed according to the embodiments of the invention. The IoT system can preset to provide different gateway devices for the IoT device and the user device. The gateway devices can mutual confirm the operating state of the other one of gateway devices, and when one of the gateway devices is failed, use the non-failed gateway device to replace the failed gateway device. As a result, the IoT system can recover rapidly from the failed operation state, such that the entire IoT system can provide high availability. In addition, the charging system with high availability may also be constructed based on the concept of aforesaid IoT system according to the embodiments of the invention.

To make the above features and advantages of the invention more comprehensible, several embodiments accompanied with drawings are described in detail as follows.

The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

FIG. 1 is a schematic diagram of an IoT system according to an embodiment of the invention.

FIG. 2 is a schematic diagram of a charging system based on IoT according to an embodiment of the invention.

FIG. 3 is a flowchart of steps in a fail recovery method of the IoT system according to an embodiment of the invention.

FIG. 4 is a flowchart of steps for confirming an operation state and a fault type of the gateway device according to an embodiment of the invention.

FIG. 5 is a schematic diagram of a fail recovery flow taken when the wired transmission circuit of the gateway device is failed according to an embodiment of the invention.

FIG. 6 is a schematic diagram of a fail recovery flow taken when the core hardware circuit of the gateway device is failed according to an embodiment of the invention.

FIG. 7 is a schematic diagram of a fail recovery flow taken when the wireless transmission circuit of the gateway device is failed according to an embodiment of the invention.

FIG. 8 is a schematic diagram of a fail recovery flow taken when the network line of the switch is disconnected according to an embodiment of the invention.

FIG. 9 is a schematic diagram of a data synchronization flow of the gateway device according to an embodiment of the invention.

FIG. 10 is a schematic diagram of a data synchronization flow of the gateway device according to another embodiment of the invention.

Reference will now be made in detail to the present preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the description to refer to the same or like parts.

In order to make content of the present disclosure more comprehensible, embodiments are described below as the examples to prove that the present disclosure can actually be realized. Moreover, elements/components/steps with same reference numerals represent same or similar parts in the drawings and embodiments.

FIG. 1 is a schematic diagram of an IoT system according to an embodiment of the invention. Referring to FIG. 1 , an IoT system 100 of the present embodiment includes a plurality of gateway devices 110 _ 1 to 110 _ n , where n is a positive integer greater than or equal to 2.

Among the gateway devices 110 _ 1 to 110 _ n , at least one gateway device (the gateway device 110 _ 1 is taken here as the example of that) is preset to provide a wireless network service to an IoT device IoTD so the IoT device IoTD can transmit respective operation information and data back to a data center (not illustrated) at front end through the gateway device 110 _ 1 , and a system administrator can also control operation behaviors of the corresponding IoT device IoTD through the gateway device 110 _ 1 .

On the other hand, among the gateway devices 110 _ 1 to 110 _ n , in addition to the gateway device 110 _ 1 preset to provide the wireless network service, at least one gateway device (the gateway device 110 _ 2 is taken here as the example of that) is further included and preset to provide the wireless network service to a user device UD so the user device UD is capable of connecting to the Internet through the gateway device 110 _ 2 . In the application of IoT, the IoT device IoTD may be implemented by selectively using stationary home appliances such as charging station, air conditioning, refrigerator, TV, refrigerator and so on, depending on the overall system requirements. The user device UD may be implemented by using general mobile electronic equipments provided for the user to operate, such as vehicle or cell phone. However, the invention is not limited to aforesaid examples.

In the present exemplary embodiment, each of the gateway devices 110 _ 1 to 110 _ n includes a wireless transmission circuit, a wired transmission circuit and a core hardware circuit. Taking the gateway device 110 _ 1 for example, it includes a wireless transmission circuit 112 , a wired transmission circuit 114 and a core hardware circuit. CHC. Among them, the core hardware circuit CHC includes hardware parts such as a memory circuit 116 and a processing unit 118 . The wireless transmission circuit 112 is coupled to the processing unit 118 , and adapted to connect the user device UD and the IoT device IoTD nearby in a wireless manner. The wireless transmission circuit 112 may be implemented by using a wireless transceiver or a wireless network card, and the wireless transceiver or the wireless network card is compatible with a wireless communication protocol such as wireless fidelity protocol (Wi-Fi protocol).

The wired transmission circuit 114 is coupled to the processing unit 118 , and adapted to connect other gateway devices 110 _ 2 to 110 _ n in a wired manner. The wired transmission circuit 114 is compatible with a wired network protocol such as Ethernet, fast Ethernet (100BASE-T) and gigabit Ethernet, but the invention is not limited to the above.

The memory circuit 116 is coupled to the processing unit 118 , and may be composed of a random access memory (RAM), a read only memory (ROM), a cache memory and components similar to the above or a combination of the above. In the present exemplary embodiment, the memory circuit 116 is configured to store a plurality of modules, and these modules may be stored in form of programs or applications in the memory circuit 116 to provide different functions.

The processing unit 118 is a hardware having a computing capability and capable of controlling operations of the gateway device 110 _ 1 (e.g., a chip set, a processor, etc.). In the present exemplary embodiment, the processing unit 118 may be a central processing unit (CPU) or any programmable microprocessor or digital signal processor (DSP), a programmed controller, an application specific integrated circuits (ASIC), a programmable logic device (PLD) or similar devices. The processing unit 118 can access the modules stored in the memory circuit 116 and execute the functions of these modules.

In addition, in an exemplary embodiment, the gateway devices 110 _ 1 to 110 _ n of the present embodiment may further preset to connect one another through a switch 120 . In other words, the wired transmission circuit 114 of each of the gateway devices 110 _ 1 to 110 _ n may exchange packets and data through the switch 120 . However, the invention is not limited thereto.

Specifically, the modules stored in the memory circuit 116 of the gateway device 110 _ 1 includes a fail recovery module ERM, a connection state confirmation module CSM, a service module SM, a network connection module NCM and a backup module BUM.

The fail recovery module ERM is configured to take over a service providing target of the failed one of the gateway device 110 _ 1 to 110 _ n when one of the gateway devices 110 _ 1 to 110 _ n is determined as failed. The connection state confirmation module CSM is configured to exchange a confirmation packet with the other gateway devices 110 _ 1 to 110 _ n so as to confirm operation states of itself and the other gateway devices 110 _ 1 to 110 _ n . The service module SM is configured to enable or disable a corresponding service function according to the current service providing target. The network connection module NCM is configured to periodically send a connection state confirmation packet via a network line WAN 1 /WAN 2 in use, and confirm whether the network line WAN 1 /WAN 2 in use is normally connected by determining whether a connection state confirmation response is received. The backup module BUM is configured to synchronize a set monitoring parameter to another one of the gateway devices 110 _ 1 to 110 _ n or upload the monitoring parameter to a cloud server. As such, when one of the gateway devices 110 _ 1 to 110 _ n is failed, the rest of the gateway devices 110 _ 1 to 110 _ n can successfully take over the service function of the failed one of the gateway devices 110 _ 1 to 110 _ n according to the monitoring parameter of the failed one of the gateway devices 110 _ 1 to 110 _ n.

In terms of the overall system operation, the user device UD may be connected to the data center of the IoT system 100 via a wireless network service provided by the corresponding gateway device 110 _ 2 . After several settings are completed (e.g., necessary information is inputted and a desired service is selected by the user, etc.), the data center can enable the IoT device IoTD through the gateway device 110 _ 1 to interact with the user device UD. Among them, during the interaction of the IoT device IoTD and the user device UD, the IoT device IoTD may also transmit information and data in the interaction back to the data center through the wireless network service provided by the gateway device 110 _ 1 so the system administrator can perform optimization, analysis or other necessary measures according to the collected information.

In a specific application example, the IoT system 100 may be, for example, a charging system based on IoT, as shown in FIG. 2 . A charging system 200 of the present embodiment includes a charging device IoTD (i.e., the IoT device in the foregoing embodiment), a gateway device 210 iot preset to provide the wireless network service to the charging device IoTD, a gateway device 210 ud preset to provide the wireless network service to the user device UD, a switch 220 and a data center 230 .

The charging device IoTD includes a charging circuit CGC, an operation monitoring circuit OMC and a communication circuit CMC. Among them, the charging circuit CGC is configured to charge the user device UD. The operation monitoring circuit OMC is configured to collect charging data while charging the user device UD. The communication circuit CMC is configured to communicate with the corresponding gateway device 210 iot , so as to transmit the collected charging data back to the corresponding gateway device 210 iot , and then transmit the collected charging data back to the data center 230 through the gate device 210 iot.

The switch 220 connects the wired transmission circuits of the gateway devices 210 iot and 210 ud , where the switch 220 has a plurality of network lines (although only two network lines WAN 1 and WAN 2 are illustrated in the present embodiment as an example, the invention is not limited thereto). The switch 220 uses one of the network lines WAN 1 and WAN 2 to provide an internet service to the gateway devices 210 iot and 210 ud . Among them, the network line WAN 1 /WAN 2 not in use is equivalent to a backup line for the network line WAN 1 /WAN 2 in use, and the switch 220 can automatically switch to use the backup line to provide the internet service instead when the network line WAN 1 /WAN 2 in use is determined as disconnected.

The data center 230 is adapted to communicate with the gateway devices 210 iot and 210 ud , and configured to store and process data messages of the charging device IoTD and the user device UD. Among them, the data center 230 may include, for example, two different target servers TS 1 and TS 2 and a cloud server CS. Under preset settings, the user device UD may be connected to the data center 230 through the gateway device 210 ud to request for enabling a charging function of the charging device IoTD or inquiring for information such as a charged state. Further, the data center 230 can give a control command to the charging device IoTD through the gateway device 210 iot . In embodiments of the invention, the target servers TS 1 and TS 1 may be inside the data center, such as 230 , or any ICMP server in the internet.

Under the architecture of the charging system 200 of the present embodiment, the user may connected to the data center 230 through the gateway device 210 ud and the switch 220 , and download an application required for using the charging device IoTD or register related information for enabling the charging function of the charging device IoTD. After the settings are completed, the data center 230 may then control the charging device IoTD through the gateway device 210 iot and the switch 220 to start charging the user device UD. During the charging process, the charging device IoTD may also transmit charging information back to the data center 230 for storage through the gateway device 210 iot and the switch 220 .

Specifically, in the traditional architecture of the IoT system, the same gateway device is usually applied to provide the wireless network service to the IoT device and the user device. Once the gateway device is failed, the IoT system can no longer operate.

In contrast, the multiple gateway devices 110 _ 1 and 110 _ 2 / 210 iot and 210 ud are disposed in the IoT system 100 or the charging system 200 of the present embodiment. As such, the gateway devices 110 _ 1 and 110 _ 2 / 210 iot and 210 ud of the present embodiment can realize an automated fail recovery by applying the steps in the flowchart of FIG. 3 . Accordingly, when one of the gateway devices is failed, a non-failed gateway device may be switched to simultaneously provide the wireless network service to the user device UD and the IoT device IoTD so the entire IoT system 100 can provide high availability.

The method illustrated in FIG. 3 is performed by the modules stored in the corresponding memory circuit 116 accessed and executed by the gateway device. FIG. 3 is a flowchart of steps in a fail recovery method of the IoT system according to an embodiment of the invention.

Here, the related description is provided below using the architecture of FIG. 1 together with the method of FIG. 3 . Referring to FIG. 1 and FIG. 3 together, first of all, the multiple gateway devices 110 _ 1 to 110 _ n are provided in the IoT system 100 , in which the gateway devices 110 _ 1 and 110 _ 2 are preset to provide the wireless network service to the IoT device IoTD and the user device UD, respectively (step S 310 ).

Under such architecture, the IoT system 100 can use the gateway devices 110 _ 1 and 110 _ 2 to mutual confirm an operation state of the other one (step S 320 ). When one of the gateway devices 110 _ 1 and 110 _ 2 is determined as failed, another one of the gateway devices 110 _ 1 and 110 _ 2 is used to replace the failed gateway device, so as to simultaneously provide the wireless network service to the IoT device IoTD and the user device UD by the non-failed gateway device (step S 330 ).

More specifically, specific steps for confirming the operation states of the gateway devices 110 _ 1 and 110 _ 2 are as illustrated in FIG. 4 . FIG. 4 is a flowchart of steps for confirming an operation state and a fault type of the gateway device according to an embodiment of the invention.

Referring to FIG. 1 to FIG. 4 together, description herein is provided below with the gateway device 110 _ 1 taken as the main part. In step S 320 , the processing unit 118 first execute the connection state confirmation module CSM to make the wired transmission circuit 114 sending a confirmation packet to the gateway device 110 _ 2 (step S 321 ) and determining whether the confirmation packet sent by the gateway device 110 _ 2 is received (step S 322 ). Here, said confirmation packet may be, for example, a heartbeat packet containing a host state.

If the processing unit 118 determines that the confirmation packet sent by the gateway device 110 _ 2 is received and the operation state of the gateway device 110 _ 2 indicated in the confirmation packet is normal, it is then determined that the two gateway devices 110 _ 1 and 110 _ 2 both operate normally (step S 323 ).

If the processing unit 118 determines that the confirmation packet sent by the gateway device 110 _ 2 is not received, whether a time within which the confirmation packet is not received exceeds a preset time (step S 324 ). If the preset time is not exceeded, the processing unit 118 continues to determine whether the confirmation packet is received; otherwise, if the confirmation packet is still not received when the preset time expires, the processing unit 118 performs a connection state confirmation procedure so as to determine a fault type of the gateway devices 110 _ 1 and 110 _ 2 (step S 325 ).

After the connection state confirmation procedure is performed, the processing unit 118 can determine whether the fault type of the gateway devices 110 _ 1 and 110 _ 2 belongs to the wired transmission circuit 114 failed (step S 326 ), the core hardware circuit CHC failed (step S 327 ) or the wireless transmission circuit 112 failed (step S 328 ). Accordingly, the processing unit 118 may transmit the detected fault information back to the data center (step S 329 ), and then execute the fail recovery module ERM and the service module SM to make the non-failed gateway device 110 _ 1 / 110 _ 2 replacing the functions of the failed gateway device 110 _ 1 / 110 _ 2 (step S 330 ).

Interactions between the IoT device IoT and the gateway devices 110 _ 1 and 110 _ 2 are used as an example for describing the fail recovery method and specific steps in the connection state confirmation procedure according to the present embodiment. FIG. 5 , FIG. 6 and FIG. 7 illustrate the fail recovery flows of the gateway device 110 _ 1 when the wired transmission circuit 114 failed, the core hardware circuit CHC failed and the wireless transmission circuit 112 failed, respectively. Further, FIG. 8 illustrates a fail recovery flow taken when the network line WAN 1 of the switch 120 is disconnected.

Person with ordinary skill in the art should be able to understand how to realize similar fail recovery method between the user device UD and the gateway devices 110 _ 1 and 110 _ 2 based on the following description, and thus interactions between other user devices UD and the gateway device 110 _ 2 is not repeated hereinafter.

FIG. 5 is a schematic diagram of a fail recovery flow taken when the wired transmission circuit of the gateway device is failed according to an embodiment of the invention. Referring to FIG. 1 and FIG. 5 together, in the case where both the gateway devices 110 _ 1 and 110 _ 2 operate normally, the gateway device 110 _ 1 regularly sends a confirmation packet HBP to the gateway device 110 _ 2 (step S 501 ). When the confirmation packet HBP sent by the gateway device 110 _ 1 is received by the gateway device 110 _ 2 , the gateway device 110 _ 2 records the state of the gateway device 110 _ 1 according to a content of the confirmation packet HBP.

Similarly, the gateway device 110 _ 2 also regularly sends the confirmation packet HBP to the gateway device 110 _ 1 (step S 502 ). When the confirmation packet HBP sent by the gateway device 110 _ 2 is received by the gateway device 110 _ 1 , the gateway device 110 _ 1 records the state of the gateway device 110 _ 2 according to a content of the confirmation packet HBP. Since it is preset to exchange the confirmation packet HBP between the gateway devices 110 _ 1 and 110 _ 2 by using the wired transmission circuit 114 , “LC” (a wired network connection) is annotated after the confirmation packet HBP hereinafter.

At this point, because the gateway devices 110 _ 1 and 110 _ 2 confirm that both sides are in the state of normally operating, the IoT device IoTD can send a connection request to the gateway device 110 _ 1 preset to provide the service (step S 503 ). After confirming that the connection request may be authorized, the gateway device 110 _ 1 transmits a connection confirmation response back to the IoT device IoTD through the wireless transmission circuit 112 (step S 504 ), and establishes a wireless network connection with the IoT device IoTD.

It is assumed that, after the wireless network connection is successfully established, the wired transmission circuit 114 of the gateway device 110 _ 1 is failed (e.g., the network is failed). In this case, the gateway device 110 _ 1 is unable to send the confirmation packet HBP to the gateway device 110 _ 2 through the wired transmission circuit 114 . Also, when the gateway device 110 _ 2 sends the confirmation packet HBP to the gateway device 110 _ 1 through the wired transmission circuit 114 (step S 505 ), the gateway device 110 _ 1 is also unable to receive the confirmation packet HBP sent from the gateway device 110 _ 2 .

Under such circumstance, after determining that the confirmation packet sent HBP from the other one of the gateway devices 110 _ 1 and 110 _ 2 is still not received after the preset time expires, each of the gateway devices 110 _ 1 and 110 _ 2 sends a connection state confirmation packet ICMP to a wired network gateway in the switch 120 (steps S 506 and S 507 ), so as to confirm whether the operation state of the respective wired transmission circuit 114 is normal.

Because the gateway device 110 _ 2 , which is not failed at the time, is able to receive a connection state confirmation response ICMP_R transmitted back from the wired network gateway in the switch 120 and determine that the respective wired transmission circuit 114 operates normally. On the other hand, since the wired transmission circuit 114 is failed, the gateway device 110 _ 1 cannot receive the connection state confirmation response ICMP_R transmitted back from the wired network gateway in the switch 120 . After the preset time expires, the gateway device 110 _ 1 determines the respective wired transmission circuit 114 as failed (step S 509 ).

After the respective transmission circuit 114 is determined as failed, the gateway device 110 _ 1 enables a station mode of the wireless transmission circuit 112 so as to attempt establishing a connection with the gateway device 110 _ 2 via a wireless network (step S 510 ). After receiving the connection request, the gateway device 110 _ 2 establishes the wireless network connection between the gateway devices 110 _ 1 and 110 _ 2 in response to the connection request for the wireless network from the gateway device 110 _ 1 (step S 511 ). The gateway device 110 _ 2 also enables the station mode of the wireless transmission circuit 112 so as to attempt establishing a connection with the gateway device 110 _ 1 via the wireless network. After receiving the connection request, the gateway device 110 _ 1 establishes the wireless network connection between the gateway devices 110 _ 1 and 110 _ 2 in response to the connection request for the wireless network from the gateway device 110 _ 2 .

After the wireless network connection between the gateway devices 110 _ 1 and 110 _ 2 is established, the gateway device 110 _ 1 sends the confirmation packet HBP to the gateway device 110 _ 2 via a wireless network connection WC instead (step S 512 ). After receiving the confirmation packet HBP, the gateway device 110 _ 2 records the state of the gateway device 110 _ 1 and learned that the wired transmission circuit 114 of the gateway device 110 _ 1 is failed. Similarly, the gateway device 110 _ 2 sends the confirmation packet HBP to the gateway device 110 _ 1 via the wireless network connection WC instead (step S 513 ). After receiving the confirmation packet HBP, the gateway device 110 _ 1 records the state of the gateway device 110 _ 2 and learned that the gateway device 110 _ 2 operates normally.

At this time, each of the gateway devices 110 _ 1 and 110 _ 2 has learned the operation state of the other one of the gateway devices 110 _ 1 and 110 _ 2 . Because the gateway device 110 _ 1 is failed, the gateway device 110 _ 1 disables the respective wireless network (step S 514 ) so the wireless network connection between the IoT device IoTD and the gateway device 110 _ 1 is disconnected. Meanwhile, the gateway device 110 _ 2 incorporates the service of the gateway device 110 _ 1 to be provided to the IoT device IoTD while continuously executing the service to be provided to the user device UD (step S 515 ). In other words, the gateway device 110 _ 2 enables a corresponding service function according to a service providing target (the IoT device IoTD) of the failed gateway device 110 _ 1 .

Thereafter, the IoT device IoTD attempts establishing the wireless network connection with the gateway device 110 _ 2 instead (step S 516 ), and the gateway device 110 _ 2 controls the IoT device IoTD instead after the connection request of the IoT device IoTD is confirmed by the gateway device 110 _ 2 (step S 517 ).

FIG. 6 is a schematic diagram of a fail recovery flow taken when the core hardware circuit of the gateway device is failed according to an embodiment of the invention. Next, referring to FIG. 1 and FIG. 6 together, in the case where both the gateway devices 110 _ 1 and 110 _ 2 operate normally, the gateway device 110 _ 1 regularly sends the confirmation packet HBP to the gateway device 110 _ 2 via a wired network LC (step S 601 ). When the confirmation packet HBP sent by the gateway device 110 _ 1 is received by the gateway device 110 _ 2 , the gateway device 110 _ 2 records the state of the gateway device 110 _ 1 according to a content of the confirmation packet HBP.

Similarly, the gateway device 110 _ 2 also regularly sends the confirmation packet HBP to the gateway device 110 _ 1 via the wired network LC (step S 602 ). When the confirmation packet HBP sent by the gateway device 110 _ 2 is received by the gateway device 110 _ 1 , the gateway device 110 _ 1 records the state of the gateway device 110 _ 2 according to a content of the confirmation packet HBP.

At this point, the gateway devices 110 _ 1 and 110 _ 2 confirm that both sides are at the state of normally operating, so the IoT device IoTD can send a connection request to the gateway device 110 _ 1 preset to provide the service (step S 603 ). After confirming that the connection request may be authorized, the gateway device 110 _ 1 transmits a connection confirmation response back to the IoT device IoTD through the wireless transmission circuit 112 (step S 604 ), and establishes the wireless network connection with the IoT device IoTD.

It is assumed that, after the wireless network connection is successfully established, the core hardware circuit CHC of the gateway device 110 _ 1 is failed. At the time, neither the wired transmission circuit 114 nor the wireless transmission circuit 112 of the gateway device 110 _ 1 can operate normally.

Under such circumstance, the gateway device 110 _ 2 still sends the confirmation packet HBP via the wired network LC (step S 605 ), and after determining that the confirmation packet HBP sent from the gateway device 110 _ 1 is still not received after the preset time expires, sends the connection state confirmation packet ICMP to the wired network gateway in the switch 120 (steps S 606 ), so as to confirm whether the operation state of the respective wired transmission circuit 114 is normal.

When the connection state confirmation response ICMP_R transmitted back from the switch 120 is received by the gateway device 110 _ 2 (step S 607 ), the gateway device 110 _ 2 can then determine the respective wired transmission circuit 114 operates normally. In this case, the gateway device 110 _ 2 enables the station mode of the wireless transmission circuit 112 so as to attempt establishing a connection with the gateway device 110 _ 2 via the wireless network in order to send the confirmation packet HBP to the gateway device 110 _ 1 via the wireless network (step S 608 ).

Nonetheless, since the gateway device 110 _ 1 is already failed and unable to transmit back the confirmation packet HBP, the gateway device 110 _ 2 can determine the core hardware circuit CHC of the gateway device 110 _ 1 as failed after the preset time expires (step S 609 ). Meanwhile, the gateway device 110 _ 2 incorporates the service of the gateway device 110 _ 1 to be provided to the IoT device IoTD while continuously executing the service to be provided to the user device UD (step S 610 ). In other words, the gateway device 110 _ 2 enables a corresponding service function according to a service providing target (the IoT device IoTD) of the failed gateway device 110 _ 1 .

Thereafter, the IoT device IoTD attempts establishing the wireless network connection with the gateway device 110 _ 2 instead (step S 611 ), and the gateway device 110 _ 2 controls the IoT device IoTD instead after the connection request of the IoT device IoTD is confirmed by the gateway device 110 _ 2 (step S 612 ).

FIG. 7 is a schematic diagram of a fail recovery flow taken when the wireless transmission circuit of the gateway device is failed according to an embodiment of the invention. Next, referring to FIG. 1 and FIG. 7 together, in the case where both the gateway devices 110 _ 1 and 110 _ 2 operate normally, operations of the gateway devices 110 _ 1 and 110 _ 2 (steps S 701 to S 704 ) are substantially identical to steps S 501 to S 504 and S 601 to S 604 in the foregoing embodiments, which are not repeated hereinafter.

It is assumed herein that, after the wireless network connection is successfully established, the wireless transmission circuit 112 of the gateway device 110 _ 1 is failed (e.g., the wireless network card is failed). In this case, the wireless network connection between the gateway device 110 _ 1 and the IoT device IoTD is disconnected, but transmission between the gateway devices 110 _ 1 and 110 _ 2 can still be conducted via a wired network.

In the present embodiment, the operation state of the respective wireless transmission circuit 112 is constantly checked during the operations of the gateway devices 110 _ 1 and 110 _ 2 . Therefore, when the wireless transmission circuit 112 of the gateway device 110 is failed, the gateway device 110 _ 1 can determine the respective wireless transmission circuit 112 as failed in real time according to a detecting result of the operation state (step S 705 ).

When the gateway device 110 _ 1 determines the respective wireless transmission circuit as failed, the gateway device 110 _ 1 adds an error code to the sent confirmation packet indicating that the wireless transmission circuit 112 is failed (step S 706 ), and transmits the confirmation packet HBPe added with the error code to the gateway device 110 _ 2 via the wired network LC (step S 707 ). On the other hand, because the gateway device 110 _ 2 operates normally, the gateway device 110 _ 2 sends the normal confirmation packet HBP to the gateway device 110 _ 1 (step S 708 ).

When the confirmation packet HBPe added with the error code is received by the gateway device 110 _ 2 , the gateway device 110 _ 2 can determine the wireless transmission circuit 112 of the gateway device 110 _ 1 as failed according to the error code (step S 709 ). In this case, the gateway device 110 _ 2 incorporates the service of the gateway device 110 _ 1 to be provided to the IoT device IoTD while continuously executing the service to be provided to the user device UD (step S 710 ). In other words, the gateway device 110 _ 2 enables a corresponding service function according to a service providing target (the IoT device IoTD) of the failed gateway device 110 _ 1 .

Thereafter, the IoT device IoTD attempts establishing the wireless network connection with the gateway device 110 _ 2 instead (step S 710 ), and the gateway device 110 _ 2 controls the IoT device IoTD instead after the connection request of the IoT device IoTD is confirmed by the gateway device 110 _ 2 (step S 711 ).

FIG. 8 is a schematic diagram of a fail recovery flow taken when the network line of the switch is disconnected according to an embodiment of the invention. FIG. 2 illustrates the whole network architecture, and thus the present embodiment is described together with the architecture of FIG. 2 . In the present embodiment, the servers TS 1 and TS 2 may be, for example, a server supporting the ICMP protocol such as a domain name system (DNS) server of an internet service provider (ISP), but the invention is not limited thereto. A routing table in the switch 220 may be configured with a static route of IP addresses of the servers TS 1 and TS 2 so packets sent from the gateway device to the server TS 1 are assigned to take the network line WAN 1 while the packets sent to the server TS 2 are assigned to take the network line WAN 2 . In the present embodiment, the IoT system/charging system 200 is preset to use the network line WAN 1 for transmitting the packets.

Referring to FIG. 2 and FIG. 8 together, description herein is provided below with the gateway device 210 iot taken as the main part. First of all, the gateway device 210 iot regularly/periodically sends the connection state confirmation packet ICMP to the server TS 1 . Because of the static route is configured in the routing table of the switch 220 , the packets with destination being the server TS 1 are sending towards the network line WAN 1 . Therefore, the connection state confirmation packet ICMP is sent from the gateway device 210 iot to the switch 220 (step S 801 ), then uploaded to the Internet via the network line WAN 1 (step S 802 ), and transmitted to the server TS 1 via the Internet (step S 803 ).

After receiving the connection state confirmation packet ICMP, the sever TS 1 transmit a connection state confirmation response ICMP_R back to the gateway device 210 iot (steps S 804 to S 806 ) via the same path (the server TS 1 →the Internet→the network line WAN 1 →the switch→the gateway device 210 iot ). If the connection state confirmation response ICMP_R is received by the gateway device 210 iot , the network line WAN 1 may be determined as normally connected. Similarly, the gateway device 210 iot may also use the similar method to detect whether the network line WAN 2 is normally connected, as shown by steps S 807 to S 812 .

After step S 812 , the gateway device 210 iot determines that the two network lines WAN 1 and WAN 2 are both in a normal connected state. Therefore, the preset network line WAN 1 is used to upload data to the Internet (steps S 813 and S 814 ), and the network line WAN 1 is also used to download data from the Internet (steps S 815 and S 816 ).

It is assumed that the network line WAN 1 in use is disconnected. In this case, after confirming that sending of the connection state confirmation packet ICMP shows consecutive failures (steps S 817 and S 818 ; two consecutive failures are taken as an example herein, but the invention is not limited thereto), the gateway device 210 iot determines the network line WAN 1 in use as disconnected, and switches the network line in use to WAN 2 (step S 819 ). Accordingly, the network line WAN 2 is used by the gateway device 210 iot to upload data to the Internet (steps S 820 and S 821 ) and download data from the Internet instead (steps S 822 and S 823 ).

Embodiments of FIG. 9 and FIG. 10 illustrate a data backup/synchronizing method of each gateway device in the IoT system according to the embodiments of the invention.

Referring to FIG. 1 and FIG. 9 , in the present embodiment, each of the gateway devices 110 _ 1 and 110 _ 2 sets the respective monitoring parameter in advance (steps S 901 and S 902 ). The monitoring parameter may be operation state parameters or operation setup files of the IoT device IoTD and the user device UD, which are not particularly limited in the invention.

In the case where the monitoring parameter of each of the gateway devices 110 _ 1 and 110 _ 2 does not change, the gateway devices 110 _ 1 and 110 _ 2 do not perform any synchronizing action. When the monitoring parameter of the gateway device 110 _ 1 changes, the gateway device 110 _ 1 synchronizes the changed monitoring parameter to the gateway device 110 _ 2 (step S 903 ). Similarly, when the monitoring parameter of the gateway device 110 _ 2 changes, the gateway device 110 _ 2 also synchronizes the changed monitoring parameter to the gateway device 110 _ 1 in real time (step S 904 ).

Accordingly, the information obtained by the gateway devices 110 _ 1 and 110 _ 2 can maintain synchronized at all time. By doing so, once one of gateway device 110 _ 1 / 110 _ 2 is failed, another one of gateway devices 110 _ 2 / 110 _ 1 can immediately replace the failed gateway device 110 _ 1 / 110 _ 2 .

In practical applications, the gateway devices 110 _ 1 and 110 _ 2 can use the Linux kernel subsystem, inotify, to realize the functions of monitoring data and configuration files as described above. For example, when a content of a monitored file changes, inotify transmits back a status code so the gateway device 110 _ 1 / 110 _ 2 can recall rsync to synchronize the changed file to another gateway device 110 _ 1 / 110 _ 2 .

Next, referring to FIG. 1 and FIG. 10 , in the present embodiment, each of the gateway devices 110 _ 1 and 110 _ 2 also sets the respective monitoring parameter in advance (steps S 1001 and S 1002 ). Unlike the embodiment of FIG. 9 , the gateway devices 110 _ 1 and 110 _ 2 periodically upload the monitoring parameter to the cloud server CS.

Specifically, as shown in FIG. 10 , each the gateway devices 110 _ 1 and 110 _ 2 uploads the set monitoring parameter to the cloud server CS (steps S 1003 and S 1004 ), and uploads the set monitoring parameter to cloud server CS again after waited for a fixed time interval PT (steps S 1005 and S 1006 ). Similarly, after steps S 1005 and S 1006 , the gateway devices 110 _ 1 and 110 _ 2 uploads the set monitoring parameter to the cloud server CS once again after waited for the time interval PT (steps S 1007 and S 1008 ), and so on and so forth.

Accordingly, once one of gateway device 110 _ 1 / 110 _ 2 is failed, another one of gateway device 110 _ 2 / 110 _ 1 can then download the monitoring parameter of the failed gateway device 110 _ 1 / 110 _ 2 from the cloud server CS in order to replace the failed gateway device 110 _ 1 / 110 _ 2 .

In summary, the fail recovery method and the IoT system and the charging system using the same are proposed according to the embodiments of the invention. The IoT system can preset to provide different gateway devices for the IoT device and the user device. The gateway devices can mutual confirm the operating state of the other one, and when one of the gateway devices is failed, use the non-failed gateway device to replace the failed gateway device. As a result, the IoT system can recover rapidly from the failed operation state, such that the entire IoT system can provide high availability. In addition, the charging system with high availability may also be constructed based on the concept of aforesaid IoT system according to the embodiments of the invention.

It will be apparent to those skilled in the art that various modifications and variations can be made to the structure of the present invention without departing from the scope or spirit of the invention. In view of the foregoing, it is intended that the present invention cover modifications and variations of this invention provided they fall within the scope of the following claims and their equivalents.