A data exchange method and system for government hall equipment

Abstract

The present invention discloses a data exchange method and model for government hall equipment, belonging to the field of electronic government information technology. The method processes data notification based on the middleware of the MQTT protocol, uses the publish / subscribe mode of its message queue, and quickly notifies the relevant equipment of data changes; the equipment initialization data is first read from the server side, and the network between the equipment and the server is connected after the equipment software is installed. The equipment software configuration only needs to configure the address of the server, and then pull other basic configuration data from the server. The present invention can adapt to the complex network environment of the government hall, the situation where the equipment is diverse and the model is not fixed, reduce the difficulty of development and maintenance, reduce the workload of deployment and implementation, and can be applicable to the agile development requirements with rapidly changing requirements.

Description

Technical Field

[0001] The present invention relates to the field of electronic government information technology, and in particular to a data exchange method and model for government hall equipment. Background Art

[0002] The data exchange of equipment in the government service hall is generally done in a point-to-point manner, that is, the sender transmits data directly to the receiver, and the data calculation and storage mostly remain on the equipment. This transmission method seems simple and convenient, but there are many problems in actual application deployment. First, the network environment of the government service hall is complex: the government intranet, the Internet, wired network, and wireless network are mixed, which may cause the equipment to be connected to different networks, and the work of connecting the network is complicated; second, the quality of equipment in the government service hall is uneven, and some old equipment has weak computing power, and the response time to some complex business logic cannot keep up with the functional requirements; third, the placement of equipment is changeable, and there may be a requirement to power off and shut down every night, which may cause the network address of the equipment to change, configuration information loss, etc., and some placement locations are difficult to operate, and it is difficult for on-site implementation personnel to handle.

[0003] In terms of data exchange, in order to keep the data of each device updated synchronously, most of the time, long connections or polling requests are used. However, the data does not need to be changed in most of the time, which will result in a large number of idle long connections or invalid polling requests. When the number of devices is large, these idle and invalid connections will waste a lot of resources, increase the network burden, and slow down the response speed of the device. Summary of the invention

[0004] The technical task of the present invention is to address the above shortcomings and provide a data exchange method and model for government hall equipment, which can adapt to the complex network environment, diverse equipment and non-fixed models of the government hall, reduce the difficulty of development and maintenance, reduce the workload of deployment and implementation, and can adapt to the agile development requirements with rapidly changing needs.

[0005] The technical solution adopted by the present invention to solve its technical problem is:

[0006] A data exchange method for government hall equipment, based on the MQTT protocol middleware processing data notification, using its message queue publish / subscribe mode to quickly notify the relevant equipment of data changes;

[0007] The device initialization data is first read from the server. After the device software is installed, the network between the device and the server is connected. The device software configuration only needs to configure the server address and then pull other basic configuration data from the server.

[0008] This method is based on the MQTT (Message Queue Telemetry Transport) protocol, which improves and optimizes the shortcomings of its data transmission, and specially transforms it according to the business scenarios of the government service hall to form a technical solution model that can be widely used and implemented in the hall equipment.

[0009] Although the equipment in the government hall is diverse, it can be roughly divided into two categories: display equipment, which is only used to display data records and calculated results; interactive equipment, the main equipment for human-computer interaction, provides data entry and outputs the results of data processing in various ways. Both types of equipment require accurate and real-time data, so in terms of data transmission, middleware based on the MQTT (Message Queue Telemetry Transport) protocol is added to handle data notifications. Using the publish / subscribe mode of its message queue, data changes can be quickly notified to related devices.

[0010] The device initialization data is first read from the server. After the device software is installed, it only needs to open the network with the server and go through the server's gateway program, which can largely avoid security vulnerabilities. The device software configuration only needs to configure the server address, and then other basic configuration data can be directly pulled from the server.

[0011] Preferably, the configuration data is pulled once when the device is started, and then pulled again for update at fixed intervals, the pulled basic configuration data is temporarily saved, and the configuration work is performed on the server side.

[0012] The configuration data can be pulled once when the device starts, and can be pulled and updated again after an interval of one hour or even longer, because this data is generally not changed. The pulled basic configuration data can be temporarily saved without taking up too much hard disk space. In this way, the configuration work can be completely handed over to the server, and there is no need to run the device for configuration every time a change is made.

[0013] Specifically, the relevant equipment programs in the hall are registered on the MQTT server middleware after being turned on and connected to the Internet; the transmission of messages only carries some key data for notification. When the recipient receives the notification, it goes to the server to obtain the required data.

[0014] Furthermore, each device communicates based on topics message subject, the device registers the message subject received, and sends notifications with the message subject;

[0015] Use HTTP to obtain server-side data through the API interface.

[0016] Furthermore, the device first requests the application server, the application server saves the data, and publishes a topic message to the MQTT server; the device obtains the message notification according to the topic, and then goes to the application server to pull the saved data.

[0017] Specifically, when a device triggers a notification, it first passes through the application server. After the application server processes and converts the business logic, it saves the persistent data in the database and the temporary data in the cache. Then, when the processing structure is returned, a notification of the processing result is published. After receiving the notification, other devices that need the notification request the application server, and the application server processes the data again to obtain the desired data. The data transmission here can be decoupled and becomes a simple interaction between the client and the server. In this way, there is no need to pay attention to the logical relationship between devices, and each development and debugging is between the client and the server.

[0018] Furthermore, when the software system and hardware equipment of the hall need to connect to a third-party system or equipment, the application server is used as an external channel to provide an API interface for them to call; the third party passes the data to the application server through this interface, and the application server then sends the data to the specific device through a message;

[0019] When it is necessary to transfer the device to a third party, only the standard data transmission interface standard is specified in advance, and the third party provides the trigger interface according to the standard.

[0020] The collaborative application of MQTT is not without flaws. One of them is that it cannot communicate point-to-point and may be eavesdropped by unknown third parties. The message itself does not carry user attributes, and it is impossible to determine whether the message data is sent correctly each time. If a third-party program is successfully registered on the MQTT server, it can monitor all message data in the system without restriction and can also send messages at will, causing chaos in the system. Therefore, third-party access still needs to use the traditional interface API form, which is safer.

[0021] Furthermore, data compensation can be performed according to business scenarios. When the data needs to be displayed on the device for a long time, a scheduled task is used on the device to pull data in batches to achieve the purpose of data compensation. When the data has high real-time requirements, the device will actively trigger the message mechanism again after receiving the data to feedback the successful acquisition of the notification.

[0022] Since the notification process may fail, the device adds a timer for receiving feedback after sending the trigger message. The timer task can only be ended after receiving feedback. If no feedback is received when the timer expires, it is necessary to trigger the message again. The target device adds a processing mechanism for repeated message data, and manually processes repeated message data only once, but each time a message is received, a successful feedback is given.

[0023] The present invention also claims to protect a data exchange model for government hall equipment, which is based on the MQTT protocol and connects all hall equipment to the MQTT server and application server to implement the above-mentioned government hall equipment data exchange method.

[0024] Furthermore, the model is applied to the queuing system of the government service hall, which includes hall interaction equipment and display equipment. The hall interaction equipment includes a number-taking machine, a pager and an evaluator. The software program on the device is first registered on the MQTT server to create a message monitoring topic for each business scenario.

[0025] The number-taking operation is performed in the number-taking machine. When the number-taking machine is started, it first pulls the configuration item information from the application server for the user to perform the number-taking operation; after the number-taking information is entered, the number-taking machine device program requests the application server to obtain the number-taking result. The number-taking result returned by one side is returned to the number-taking machine and then prints the queue number ticket. The application server on the other side sends a notification of the number-taking result. The pager and display device can obtain the detailed content from the application server according to the notification and display it to the window staff;

[0026] Call: First, the window staff logs in to the pager in advance. The pager pulls the relevant information of the window and personnel and saves it locally. The window staff sees the new number-taking service displayed on the pager and can make a call. The pager first requests the application server to obtain the latest callable queue number. The queue number is first displayed on the pager to feedback the call success. The application server also publishes the call information through the MQTT server. The display device obtains the information and displays it to remind the people to go to the window to handle the business.

[0027] Evaluation: If the evaluation trigger is a third-party comprehensive acceptance system, the acceptance system and the queuing system only use the window number to correspond. The third-party system calls the application server to initiate window evaluation. The server triggers a message to the corresponding window, and the window can make a corresponding evaluation response.

[0028] Compared with the prior art, the data exchange method and model of government hall equipment of the present invention has the following beneficial effects:

[0029] The data communication line used in this method and model completely shields the network environment between devices, and does not require communication between devices. It only requires connecting all devices to the MQTT server and application server.

[0030] Because MQTT protocol messages have the characteristics of low bandwidth, light weight, and high reliability, the transmission of messages occupies fewer resources. When there is no message trigger, there is no need to keep connecting to the application server to obtain the latest data, which can also reduce the pressure on the application server.

[0031] This method further adds correct data compensation measures, and the accuracy and timing of the data are guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a structural diagram of a method for exchanging data between government hall equipment provided by an embodiment of the present invention;

[0033] Figure 2 It is a structural diagram of a method for exchanging data between government hall devices when a third-party system or device needs to be connected, provided by an embodiment of the present invention;

[0034] Figure 3 It is a structural diagram of the government service hall equipment data exchange model provided by an embodiment of the present invention applied to the queuing and calling system of the government service hall. DETAILED DESCRIPTION

[0035] The network environment of the government service hall is complex, the equipment is diverse and the models are not fixed. At the same time, we need to reduce the difficulty of development and maintenance, lighten the workload of deployment and implementation, and adapt to the requirements of agile development with rapidly changing needs. Therefore, it is necessary to define a common model to handle the data transmission, calculation, and storage methods between devices: one is to standardize the development model and fix the deployment and maintenance steps; the other is to be compatible with old equipment and reduce data occupation and waste.

[0036] The embodiment of the present invention provides a data exchange method for government hall equipment, which processes data notification based on the middleware of the MQTT protocol and uses the publish / subscribe mode of its message queue to quickly notify the relevant equipment of data changes;

[0037] The device initialization data is first read from the server. After the device software is installed, the network between the device and the server is connected. The device software configuration only needs to configure the server address and then pull other basic configuration data from the server.

[0038] Optimize the data transmission, processing and storage methods in the hardware and software equipment of the government service hall to improve resource utilization and development and deployment efficiency. Based on the MQTT (Message Queue Telemetry Transport) protocol, it is transformed according to the business scenarios of government services to solve the problems in the development and implementation process of the government service hall.

[0039] This method is based on the MQTT (Message Queue Telemetry Transport) protocol, which improves and optimizes the shortcomings of its data transmission, and specially transforms it according to the business scenarios of the government service hall to form a technical solution model that can be widely used and implemented in the hall equipment.

[0040] Although the equipment in the government hall is diverse, it can be roughly divided into two categories:

[0041] Display equipment is only used to display data records and calculated results;

[0042] Interactive devices, the main devices for human-computer interaction, provide data entry and output the results of data processing in various ways.

[0043] Both types of devices require accurate and real-time data. Therefore, in terms of data transmission, middleware based on the MQTT (Message Queue Telemetry Transport) protocol is added to handle data notifications. By using the publish / subscribe mode of its message queue, data changes can be quickly notified to related devices.

[0044] The device initialization data is first read from the server. After the device software is installed, it only needs to open the network with the server and go through the server's gateway program, which can avoid security vulnerabilities to a large extent. The device software configuration only needs to configure the server address, and then other basic configuration data can be directly pulled from the server. These configuration data can be pulled once when the device is started, and can be pulled and updated again after an interval of one hour or even longer, because this data is generally not changed. The pulled basic configuration data can be temporarily saved, and it does not need to take up too much hard disk space. In this way, the configuration work can be completely handed over to the server, and there is no need to run the device for configuration every time a change occurs.

[0045] After the relevant equipment programs in the hall are turned on and connected to the Internet, they are registered on the MQTT server middleware. Each device communicates based on the topics message subject: the device registers the message subject to be received and sends a notification with the message subject. The transmission of the message only carries some key data for notification. When the receiver receives the notification, it uses HTTP and other methods to obtain the required data from the server through the API interface.

[0046] like Figure 1As shown in the figure, first the device registers on the MQTT server and subscribes to the topic. When a device wants to notify other devices, the simplest and most direct way is to send the topic message interface directly through the MQTT message server, and other devices can receive the notification. This simple use of the MQTT message publish / subscribe mode is suitable for simple device notification scenarios and can achieve simple one-to-one and one-to-many device interactions; but limited by the lightweight and more complex business scenarios of MQTT, in most cases we cannot send a large amount of business data through messages. With the addition of MQTT components, reliable network services can be provided for IoT devices in low-bandwidth and unstable network environments, and the power consumption requirements are much lower than HTTP. The scale of devices can also support millions of clients, which makes more efficient use of hardware resources. Compared with simply using HTTP for communication, this method of using MQTT to receive notifications and then using HTTP to pull data can save more resources. Compared with polling, push is a better solution.

[0047] Extending on this basis, we get another way of interaction:

[0048] The device first requests the application server, which saves the data and publishes a topic message to the MQTT server. In this way, the device obtains message notifications based on the topic, and then goes to the application server to pull the saved data. This application method is more elegant and effective:

[0049] The device triggers a notification that first passes through the application server. After the application server processes and converts complex business logic, it saves the persistent data in the database and the temporary data in the cache. Then it returns the processing structure and publishes the processing result notification. After receiving the notification, other devices that need the notification request the application server, and the application server processes the data again to obtain the desired data. The data transmission here can be decoupled and simply becomes an interaction between the client and the server. In this way, there is no need to pay attention to the logical relationship between devices, and each development and debugging is between the client and the server.

[0050] The above is how the system handles data transmission internally.

[0051] However, in many cases, the lobby's software system, hardware equipment, etc. may need to connect to other third parties. When the lobby's software system and hardware equipment need to connect to third-party systems or equipment, the application server is used as an external channel to provide an API interface for them to call; Figure 2 As shown, the third party passes the data to the application server through this interface, and the application server then sends the data to the specific device through a message; when the device needs to be transferred to a third party, when we are in charge, we only need to specify the standard data transmission interface standard in advance, and the third party can provide a trigger interface according to the standard.

[0052] The collaborative application of MQTT is not flawless. First, it cannot communicate point-to-point and may be eavesdropped by unknown third parties. The message itself does not carry user attributes, and it is impossible to determine whether the message data is sent correctly each time. If a third-party program is successfully registered on the MQTT server, it can monitor all message data in the system without restriction and can also send messages at will, causing chaos in the system. Therefore, third-party access still needs to use the traditional interface API form, which is safer.

[0053] Second, MQTT does not support offline messages. Messages based on MQTT may also have data loss problems. Therefore, a data compensation mechanism is needed in the middle. This needs to be compensated according to the business scenario. Generally, there are two situations: when the data needs to be displayed on the device for a long time, a scheduled task is used on the device to pull data in batches to achieve the purpose of data compensation; when the data has high real-time requirements, in order to ensure that the data is accurately notified to the target device, it is necessary to actively trigger the message mechanism again after the device receives the data to feedback the successful acquisition of the notification;

[0054] Since the notification process may fail, the device adds a timer for receiving feedback after sending the trigger message. The timer task can only be ended after receiving feedback. If no feedback is received when the timer expires, it is necessary to trigger the message again. Therefore, a processing mechanism for repeated message data is added to the target device end. The repeated message data is manually processed and only processed once, but each time a message is received, a successful feedback is given.

[0055] An embodiment of the present invention also provides a data exchange model for government hall equipment. The model is based on the MQTT protocol and connects all hall equipment to the MQTT server and application server to implement the data exchange method for government hall equipment described in the above embodiment.

[0056] Here, the queuing system in the government service hall is used as an example to illustrate the data exchange model of the government service hall equipment. The interactive equipment in the hall involved in the queuing system includes number-taking machines, pagers, evaluators, etc., and the display devices include TVs, LEDs, etc.

[0057] The first step in implementing the model is to register the software program on the device on the MQTT server and create a message monitoring topic for each business scenario. Then, the following process is separated into three business scenarios: number acquisition, call, and evaluation to illustrate the implementation method:

[0058] Picking a number: The picking operation is performed in the picking machine. When the picking machine is started, it first pulls the configuration item information from the application server for the user to perform the picking operation. After the picking information is entered, the picking machine device program requests the application server to obtain the picking result. The picking result returned by one side is returned to the picking machine and then prints the queue number ticket. On the other side, the application server sends a notification of the picking result "newly added a certain queue number". The pager and TV can obtain the detailed content from the application server based on the notification and display it to the window staff.

[0059] Call: First, the window staff must log in to the pager in advance. The pager pulls the relevant information of the window and personnel and saves it locally. When the window staff sees the new number-taking service displayed on the pager, they can make a call. The pager first requests the application server to obtain the latest callable queue number. The queue number is first displayed on the pager to feedback the call success. The application server also publishes the information "The window pager called the queue number" through the MQTT server. In this way, TVs, LEDs and other devices can obtain this information and display it to remind the people to go to the window to handle their business.

[0060] Evaluation: The evaluation trigger is assumed to be a third-party comprehensive acceptance system. The acceptance system and the queuing system only use the window number to correspond. The third-party system calls the application server to initiate the evaluation of a certain window. The server triggers a message to the corresponding window, and the window can make a corresponding evaluation response. In this process, the third-party system only connects to the application server, and no device information needs to be paid attention to.

[0061] From the development perspective, the development of the number-taking machine and pager can be completely decoupled, and the interaction between the two types of devices is not reflected in the devices at all. From the implementation perspective, the network no longer emphasizes that the networks of all devices are always interconnected. It only requires that all devices can access the MQTT server and application server individually. The IP between devices no longer needs to be specified, and the configuration items are greatly reduced.

[0062] This model introduces the MQTT protocol in the data exchange of equipment programs in the government service hall, and transforms and optimizes its use according to business scenarios to create more convenient and efficient data transmission; MQTT is mixed with API interfaces to be applied in the government service hall in a better way.

[0063] Through the above specific implementations, those skilled in the art can easily implement the present invention. However, it should be understood that the present invention is not limited to the above specific implementations. On the basis of the disclosed implementations, those skilled in the art can arbitrarily combine different technical features to achieve different technical solutions.

[0064] Except for the technical features described in the specification, all other technical features are known technologies to those skilled in the art.

Claims

1. A method for exchanging data between government hall equipment, characterized in that The MQTT-based middleware processes data notifications and uses the publish / subscribe model of its message queue to quickly notify related devices of data changes. The device initialization data is first read from the server. After the device software is installed, the network between the device and the server is connected. The device software configuration only needs to configure the server address and then pull other basic configuration data from the server. The relevant equipment programs in the hall are registered on the MQTT server middleware after they are turned on and connected to the Internet; the transmission of messages only carries some key data for notification. When the receiver receives the notification, it goes to the server to obtain the required data; the device first requests the application server, which saves the data and publishes the topic message to the MQTT server; the device obtains the message notification according to the topic, and then goes to the application server to pull the saved data; Data compensation is performed according to business scenarios. When the data needs to be displayed on the device for a long time, a scheduled task is used on the device to pull data in batches to achieve the purpose of data compensation. When the data has high real-time requirements, the device will actively trigger the message mechanism again after receiving the data to feedback the successful acquisition of the notification. After the device sends the trigger message, a timer is added to receive feedback. The timer task can only be ended after receiving feedback. A mechanism for processing duplicate message data is added on the target device side. When duplicate message data is received, it is processed and only processed once, but each message received is fed back as successful. The configuration data is pulled once when the device is started, and then pulled again at fixed intervals for update. The pulled basic configuration data is temporarily saved, and the configuration work is performed on the server side; Each device communicates based on topics. The device registers the message topics it receives and sends notifications with the message topics. It uses HTTP to obtain server-side data through the API interface. When a device triggers a notification, it first passes through the application server. After the application server processes and converts the business logic, it saves the persistent data in the database and the temporary data in the cache. Then, when the processing structure is returned, the processing result notification is published. After receiving the notification, other devices that need the notification request the application server again, and the application server processes the data again to obtain the desired data.

2. A method for exchanging data between government hall equipment according to claim 1, characterized in that When the software system and hardware equipment of the hall need to connect to the third-party system or equipment, the application server is used as the external channel to provide an API interface for them to call; the third party passes the data to the application server through this interface, and the application server then sends the data to the specific device through a message; When it is necessary to transfer the device to a third party, only the standard data transmission interface standard is specified in advance, and the third party provides the trigger interface according to the standard.

3. A data exchange system for government hall equipment, characterized in that: Based on the MQTT protocol, all hall equipment is connected to the MQTT server and application server to implement the government hall equipment data exchange method described in any one of claims 1-2.

4. A data exchange system for government hall equipment according to claim 3, characterized in that The system is applied to the queuing and calling system of the government service hall. The queuing and calling system includes hall interactive equipment and display equipment. The hall interactive equipment includes a number-taking machine, a pager and an evaluator. The software program on the device is first registered on the MQTT server to create a message monitoring topic for each business scenario. The number-taking operation is performed in the number-taking machine. When the number-taking machine is started, it first pulls the configuration item information from the application server for the user to perform the number-taking operation; after the number-taking information is entered, the number-taking machine device program requests the application server to obtain the number-taking result. The number-taking result returned by one side is returned to the number-taking machine and then prints the queue number ticket. The application server on the other side sends a notification of the number-taking result. The pager and display device can obtain the detailed content from the application server according to the notification and display it to the window staff; Call: First, the window staff logs in to the pager in advance. The pager pulls the relevant information of the window and personnel and saves it locally. The window staff sees the new number-taking service displayed on the pager and can make a call. The pager first requests the application server to obtain the latest callable queue number. The queue number is first displayed on the pager to feedback the call success. The application server also publishes the call information through the MQTT server. The display device obtains the information and displays it to remind the people to go to the window to handle the business. Evaluation: If the evaluation trigger is a third-party comprehensive acceptance system, the acceptance system and the queuing system only use the window number to correspond. The third-party system calls the application server to initiate window evaluation. The server triggers a message to the corresponding window, and the window can make a corresponding evaluation response.

Images