RFID conference sign-in system summary (II)-function Overview

 

Now let's get started. First, let's briefly describe the functions of the entire system, mainly laying the groundwork for some of my designs below.

The sign-in system is divided into two parts: front-end display and background management control.

The front-end displays the information of the current Signer Based on the Information read by the hardware device, and updates the number of people who have signed in and the total number of people who have signed in by the machine in different categories. At the same time, the current network connection status is displayed. This is a basic function, which will be described later.

The backend manages the databases that sign in to the system. Some basic addition, deletion, modification, and query operations on data tables are essential, and the printing function cannot be escaped. The most important part is the management and control of the sign-in process, such as when and when the sign-in process is stopped, and then the current number of sign-in persons is displayed in semi-real time, displays the working status of all front-ends and the status of each hardware device.

So far, the functions are still quite satisfactory. However, for applications based on this system, many situations must be considered, even if the probability of these situations is very low.

First, the network is abnormal. If the on-site network is abnormal, the entire system will not be paralyzed, and the network will be restored to normal. The continued check-in process and check-in statistics will not interfere.

Consider the front-end client,RFIDHardware equipment faults are fatal if they cannot be ruled out within a short period of time. Therefore, some clients are configured with handheld devices just in case. Of course, if the network is abnormal, the sign-in control command is unacceptable, so you have to add some sign-In control actions on the front-end client. If you sign in, you must have a credential (that is, a credential containingRFIDChip certificates), but sometimes the participants may not be able to provide for various reasons, or the creden are damaged and cannot be automatically signed in, it must be supplemented by the manual sign-in function.

After considering the front-end, consider the background. The manual sign-In function mentioned above is generally performed in the background for various reasons (such as checking personnel, of course, you must manually cancel it. We have previously considered network exceptions, and we cannot rule out computer exceptions. measures such as dual-machine Hot Backup also need to be mentioned in the menu.

 

Until now, the functions are very standard and comply with our concept of a complete system. However, the sign-in system is not an isolated system. Where does the basic data come from, and the information of its attendees comes from the personnel database; where does the result come from, the statistical results of sign-in are the basis for the legitimacy of the meeting (if there is an election, it is the basis for the issuance of votes, of course, the election is based on a rigorous process of manual counting of the number of people ).

Unlike our company's attendance, the company's staff are basically fixed at that point. However, the participants in a meeting may be very different from the previous one. All of these people, whether they attended the meeting, attended the meeting, or attended the meeting twice, must be a subset of a large collection, but that big collection is impossible for us to come into contact, and even the customers who sign in to this one cannot.

Compared with attendance, the result of daily commuting and punching in will be useful in the end of the month. However, in addition to the number of students reported and the number of absent lists displayed after the event, the result of this meeting is basically useless. At least this is the case when I come into contact.

The final reality is not the same as the ideal conference sign-in system in my mind. This is a complete transaction. In this way, the system adds a batch data import function to reduce the workload of data input. For the sake of system simplicity, we temporarily think that there is no association between the data imported twice, and only the data of the current check-in meeting is stored in the database. For the sake of checking and signing data, the system has added the data backup and recovery function (it is of course unfriendly to allow the customer to use the database backup and recovery function ).

 

Of course, the design based on a single seller is not a good design. If it is not for this type of meeting, the applicability will be greatly reduced. Archiving of conference sign-in data is a function that should be considered, but the pressure on the end time and the customer did not have such requirements. Maybe this system will be added in other scenarios in the future.