門(mén)禁識(shí)別在事務(wù)消息推送中的應(yīng)用研究

許起梔，鄧穎杰，李敏，李金龍

（浙江傳媒學(xué)院，浙江 杭州 310018）

0 引 言

隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)以及5G 技術(shù)的快速發(fā)展，大數(shù)據(jù)人工智能時(shí)代的到來(lái)使得人們接收的信息大量增長(zhǎng)。傳統(tǒng)的事務(wù)消息管理仍為人工管理，管理模式缺乏合理性?，F(xiàn)階段，一些企業(yè)、高校等單位針對(duì)事務(wù)消息推送的管理普遍選擇三級(jí)管理模式，依照總部、各部門(mén)負(fù)責(zé)人、個(gè)人的順序以此向下進(jìn)行管理。在實(shí)際操作過(guò)程中，這種傳統(tǒng)的事務(wù)消息管理推送不僅效率低下，有時(shí)還會(huì)出現(xiàn)事務(wù)消息與接收對(duì)象不符的弊端。

目前，主要的消息推送工具是即時(shí)通信工具，主要有三種方式，即短信推送、消息線(xiàn)上推送和企業(yè)微信推送。這三種消息推送方式容易在接收大量的事務(wù)消息后，忽略掉其中一些未完成的事務(wù)。由此可見(jiàn)，事務(wù)消息推送管理的智能化轉(zhuǎn)型十分迫切。為了優(yōu)化事務(wù)消息推送管理方法，提高管理人員和個(gè)人的工作效率，本文基于門(mén)禁識(shí)別與事務(wù)管理對(duì)軟件系統(tǒng)及硬件設(shè)備的交互進(jìn)行了研究。

將事務(wù)消息管理系統(tǒng)和門(mén)禁識(shí)別系統(tǒng)相結(jié)合，實(shí)現(xiàn)了用戶(hù)在進(jìn)出單位通過(guò)門(mén)禁識(shí)別后第一時(shí)間收到代辦事項(xiàng)的消息推送的功能。本文所研究的系統(tǒng)具有三大特色功能：整理記錄事務(wù)消息、與門(mén)禁識(shí)別系統(tǒng)相連接、查看當(dāng)下事務(wù)消息。相較于傳統(tǒng)事務(wù)消息推送工具的一大優(yōu)勢(shì)是與門(mén)禁識(shí)別系統(tǒng)相結(jié)合，實(shí)現(xiàn)了門(mén)禁識(shí)別設(shè)備和電腦服務(wù)端、手機(jī)端APP之間的交互。因此，事務(wù)消息管理系統(tǒng)和門(mén)禁識(shí)別系統(tǒng)相結(jié)合可實(shí)現(xiàn)的功能主要有：

（1）整理記錄事務(wù)消息功能。當(dāng)發(fā)布事務(wù)消息的管理人員面臨一對(duì)多的消息發(fā)布情況時(shí)，可以直接利用數(shù)據(jù)庫(kù)管理系統(tǒng)進(jìn)行分類(lèi)，無(wú)須耗費(fèi)大量的時(shí)間將各種消息一個(gè)個(gè)通知到每一位成員，并無(wú)須等待和確認(rèn)成員們是否收到。

（2）與門(mén)禁識(shí)別系統(tǒng)相連接功能。當(dāng)工作人員上班或因事外出歸來(lái)時(shí)，經(jīng)過(guò)門(mén)禁識(shí)別系統(tǒng)后，未完成的事務(wù)消息將立馬被推送至手機(jī)，高效省時(shí)。且可與多種門(mén)禁識(shí)別方式相適應(yīng)，例如人臉識(shí)別、指紋識(shí)別或者IC 卡識(shí)別。

（3）查看當(dāng)下事務(wù)消息。當(dāng)經(jīng)過(guò)門(mén)禁識(shí)別系統(tǒng)后，指定APP即推送已完成和未完成的事務(wù)消息，并已經(jīng)根據(jù)內(nèi)容、程度等進(jìn)行了標(biāo)記，無(wú)須自己記錄和分類(lèi)，一目了然。

基于門(mén)禁識(shí)別與事務(wù)管理的消息推送系統(tǒng)的發(fā)展前景不僅限于此，如果把這一系統(tǒng)安裝于公司的智能機(jī)器人中，在用戶(hù)與智能機(jī)器人進(jìn)行交流的同時(shí)，機(jī)器人就能將最新的待辦事務(wù)消息推送到用戶(hù)的手機(jī)，對(duì)待辦事務(wù)進(jìn)行一個(gè)及時(shí)的更新，提高了工作效率。如果可以實(shí)現(xiàn)智能化消息推送與人工智能的結(jié)合，這會(huì)使通信及人工智能在廣電領(lǐng)域的事務(wù)自動(dòng)化管理發(fā)展邁出一大步。

1 事務(wù)消息推送數(shù)據(jù)傳輸設(shè)計(jì)

電腦后臺(tái)系統(tǒng)是門(mén)禁識(shí)別設(shè)備與手機(jī)端APP 之間進(jìn)行事務(wù)消息推送的“橋梁”。當(dāng)用戶(hù)通過(guò)門(mén)禁識(shí)別設(shè)備時(shí)，電腦后臺(tái)系統(tǒng)收到用戶(hù)特征ID，迅速匹配數(shù)據(jù)庫(kù)中與特征ID相同的用戶(hù)信息并提取待辦事務(wù)，然后將事務(wù)消息推送到手機(jī)端APP 的“最新事務(wù)”界面。電腦后臺(tái)系統(tǒng)與門(mén)禁識(shí)別設(shè)備信息傳輸過(guò)程如圖1所示。

圖1 事務(wù)消息集成控制與硬件數(shù)據(jù)傳輸過(guò)程

數(shù)據(jù)庫(kù)匹配用戶(hù)信息之前，需要完成三個(gè)步驟：錄入用戶(hù)個(gè)人信息（ID 及照片）；搭建用戶(hù)信息數(shù)據(jù)庫(kù)；實(shí)現(xiàn)門(mén)禁識(shí)別設(shè)備與電腦后臺(tái)系統(tǒng)之間的通信。當(dāng)前通信是通過(guò)TCP 協(xié)議（一種面向廣域網(wǎng)的通信協(xié)議，目的是在跨越多個(gè)網(wǎng)絡(luò)通信時(shí)，為兩個(gè)通信端點(diǎn)之間提供一種面向連接的、可靠的、基于字節(jié)流的通信方式）維持的。

在實(shí)現(xiàn)事務(wù)消息的推送之前，還需要完成電腦后臺(tái)系統(tǒng)與手機(jī)端APP 的連通。這里是通過(guò)MQTT 協(xié)議（一種基于二進(jìn)制消息的發(fā)布/訂閱編程模式的消息協(xié)議）將數(shù)據(jù)庫(kù)中提取出來(lái)的事務(wù)消息推送到手機(jī)端APP。

在完成整個(gè)消息推送的過(guò)程中，還需要用戶(hù)安裝對(duì)應(yīng)的手機(jī)端APP。用戶(hù)在“我的”界面完成信息注冊(cè)并登錄后，在門(mén)禁識(shí)別的同時(shí)，“最新事務(wù)”界面就能收到來(lái)自后臺(tái)服務(wù)端的待辦事務(wù)消息。用戶(hù)還可以在“事務(wù)現(xiàn)狀”界面檢查是否有遺漏的待辦事務(wù)。

2 事務(wù)消息推送集成設(shè)計(jì)

按整個(gè)消息推送流程來(lái)看，設(shè)計(jì)之初，會(huì)開(kāi)發(fā)一個(gè)錄入用戶(hù)個(gè)人特征ID 的軟件，并將特征ID 導(dǎo)入到門(mén)禁識(shí)別設(shè)備中，實(shí)現(xiàn)特征ID 比對(duì)。其次數(shù)據(jù)庫(kù)會(huì)主要圍繞用戶(hù)的特征ID 及待辦事務(wù)等進(jìn)行搭建和完善。

電腦后臺(tái)系統(tǒng)與門(mén)禁識(shí)別設(shè)備之間本質(zhì)是多條單向傳輸（n 對(duì)1），即多個(gè)門(mén)禁識(shí)別設(shè)備（客戶(hù)端）將用戶(hù)的特征ID 傳送到電腦后臺(tái)系統(tǒng)；電腦后臺(tái)系統(tǒng)與手機(jī)端APP 實(shí)質(zhì)上是1 對(duì)n 的關(guān)系，即電腦后臺(tái)系統(tǒng)將用戶(hù)的待辦事務(wù)分別發(fā)送到對(duì)應(yīng)的手機(jī)端APP（客戶(hù)端）。對(duì)應(yīng)關(guān)系如圖2所示。根據(jù)以上的描述，可以看出電腦后臺(tái)系統(tǒng)中的數(shù)據(jù)庫(kù)是非常龐大的，因此，為了高效地完成用戶(hù)信息的匹配就要借助一些數(shù)據(jù)庫(kù)管理工具（可以明確了解到數(shù)據(jù)庫(kù)中有哪些表和哪些字段，對(duì)應(yīng)的字段有哪些類(lèi)型長(zhǎng)度等，便于檢索）。

圖2 對(duì)應(yīng)關(guān)系

門(mén)禁識(shí)別設(shè)備、手機(jī)端APP 與電腦后臺(tái)系統(tǒng)的連通本質(zhì)上是與數(shù)據(jù)庫(kù)的通信，整個(gè)消息推送的實(shí)現(xiàn)離不開(kāi)對(duì)數(shù)據(jù)庫(kù)中待辦事務(wù)的提取與發(fā)送，同時(shí)涉及電腦后臺(tái)系統(tǒng)對(duì)于客戶(hù)端、服務(wù)端、發(fā)送端和接收端的選取和開(kāi)發(fā)。服務(wù)端1 在端口監(jiān)聽(tīng)門(mén)禁識(shí)別設(shè)備請(qǐng)求的TCP 連接，獲取Socket 的輸出流并向門(mén)禁識(shí)別設(shè)備發(fā)送數(shù)據(jù)獲取Socket 的輸入流，用來(lái)接收從門(mén)禁識(shí)別設(shè)備發(fā)送過(guò)來(lái)的特征ID 數(shù)據(jù)。服務(wù)端1收到特征ID 數(shù)據(jù)后作為發(fā)送端，通過(guò)UDP（一種無(wú)須建立連接的用戶(hù)數(shù)據(jù)報(bào)協(xié)議）將特征ID 數(shù)據(jù)傳送到接收端。接收端將收到的特征ID 數(shù)據(jù)先放進(jìn)數(shù)據(jù)庫(kù)中進(jìn)行匹配查找，提取了對(duì)應(yīng)的事務(wù)消息后，再作為客戶(hù)端發(fā)送到服務(wù)端2，由服務(wù)端2 通過(guò)MQTT 推送到手機(jī)端APP。電腦后臺(tái)系統(tǒng)運(yùn)行過(guò)程如圖3所示。

圖3 電腦后臺(tái)系統(tǒng)運(yùn)行過(guò)程

門(mén)禁識(shí)別設(shè)備通過(guò)TCP 向服務(wù)端1 傳輸數(shù)據(jù)，可以保證數(shù)據(jù)無(wú)差錯(cuò)、不丟失、不重復(fù)且按序到達(dá)，并且TCP 是在點(diǎn)對(duì)點(diǎn)之間傳輸，適用于此處多個(gè)門(mén)禁識(shí)別設(shè)備向電腦后臺(tái)系統(tǒng)傳輸數(shù)據(jù)的情況。服務(wù)端1 向接收端傳輸數(shù)據(jù)時(shí)運(yùn)用了UDP，相較于TCP 來(lái)說(shuō)，UDP 支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信，傳輸范圍更廣，并且傳輸效率更高，減少網(wǎng)絡(luò)堵塞的情況。服務(wù)端2 將對(duì)應(yīng)用戶(hù)的事務(wù)消息發(fā)送到手機(jī)端APP 時(shí)通過(guò)MQTT 實(shí)現(xiàn)1 對(duì)多的數(shù)據(jù)傳輸，并且MQTT 保證了數(shù)據(jù)傳輸?shù)目煽啃浴?/p>

手機(jī)端APP 針對(duì)Android、IOS 等不同的操作系統(tǒng)進(jìn)行開(kāi)發(fā)，使得每一位用戶(hù)都能下載該APP。APP 界面分為“最新事務(wù)”“事務(wù)現(xiàn)狀”及“我的”，運(yùn)用界面藝術(shù)設(shè)計(jì)會(huì)對(duì)其界面做一個(gè)美化，讓用戶(hù)體驗(yàn)感更好。

3 技術(shù)實(shí)現(xiàn)與成果展示

根據(jù)設(shè)計(jì)思路，對(duì)軟件開(kāi)發(fā)的整體技術(shù)路線(xiàn)如下：

（1）利用phpStudy的數(shù)據(jù)庫(kù)和SQL-Front 數(shù)據(jù)庫(kù)管理工具完成工作人員身份信息管理系統(tǒng)的搭建，其中包括個(gè)人信息和待通知的消息；利用Facedemo 錄入用來(lái)識(shí)別身份的特征ID，提高人員管理的效率；

（2）在Eclipse 開(kāi)發(fā)環(huán)境下，用Java 語(yǔ)言編譯出FaceRecv 軟件，實(shí)現(xiàn)與門(mén)禁識(shí)別設(shè)備的連接；

（3）在Eclipse 開(kāi)發(fā)環(huán)境下，用Java 語(yǔ)言編譯出Server軟件，實(shí)現(xiàn)與數(shù)據(jù)庫(kù)的連接；

（4）基于Mosquiito服務(wù)端，將門(mén)禁識(shí)別設(shè)備和手機(jī)APP 連接起來(lái)，從而實(shí)現(xiàn)兩個(gè)設(shè)備間的消息推送；

（5）通過(guò)移動(dòng)終端APP 實(shí)現(xiàn)對(duì)事務(wù)消息的查詢(xún)，可依據(jù)標(biāo)注好的分類(lèi)展開(kāi)工作。

軟件應(yīng)用前期，需將用戶(hù)的特征ID 錄入由phpStudy 的數(shù)據(jù)庫(kù)和SQL-Front 數(shù)據(jù)庫(kù)管理工具搭建的身份信息管理系統(tǒng)，如圖4所示。Facedemo 中的數(shù)據(jù)可直接導(dǎo)入門(mén)禁識(shí)別設(shè)備。

圖4 Facedemo 錄入特征ID

FaceRecv 可與多個(gè)門(mén)禁識(shí)別設(shè)備相連接，當(dāng)有用戶(hù)通過(guò)門(mén)禁識(shí)別設(shè)備后，設(shè)備作為客戶(hù)端通過(guò)TCP 將特征ID 數(shù)據(jù)傳送至FaceRecv 服務(wù)端，F(xiàn)aceRecv 又作為發(fā)送端通過(guò)UDP 將特征ID 數(shù)據(jù)傳送至Server 接收端，如圖5所示。

圖5 FaceRecv 工作圖

Server 是FaceRecv 的接收端，也是Mosquitto 服務(wù)端的客戶(hù)端。Server 將從FaceRecv 軟件中接收到的數(shù)據(jù)Faceid先放進(jìn)數(shù)據(jù)庫(kù)中查找，提取了對(duì)應(yīng)的事務(wù)消息后，再發(fā)送進(jìn)Mosquitto 服務(wù)端，由Mosquitto 服務(wù)端通過(guò)MQTT 服務(wù)器推送至手機(jī)端。

Mosquitto 作為Server 和手機(jī)APP 的服務(wù)端，通過(guò)MQTT 將Server 從數(shù)據(jù)庫(kù)中提取出來(lái)的事務(wù)消息發(fā)送至手機(jī)APP，如圖6所示。

圖6 Mosquitto 工作流程圖

整個(gè)智能化消息推送完成后的數(shù)據(jù)傳輸過(guò)程如下：

用戶(hù)首先需要在Facedemo 應(yīng)用軟件上注冊(cè)個(gè)人信息（ID及照片），所注冊(cè)的個(gè)人信息將被傳送到門(mén)禁識(shí)別設(shè)備。使用Mosquitto-v 命令開(kāi)啟搭建好的Mosquitto 服務(wù)器，使用ping IP 地址命令使得門(mén)禁識(shí)別設(shè)備與電腦端相互連接、電腦端與手機(jī)端相互連接。在門(mén)禁識(shí)別設(shè)備識(shí)別到用戶(hù)后，用戶(hù)的個(gè)人信息將傳送到FaceRecv 軟件上。FaceRecv 軟件把收集到的用戶(hù)信息傳送到Server 軟件上，然后Server 軟件與數(shù)據(jù)庫(kù)進(jìn)行對(duì)接，即Server 軟件將在數(shù)據(jù)庫(kù)中查詢(xún)數(shù)據(jù)，傳送到Server 軟件上的用戶(hù)信息將與數(shù)據(jù)庫(kù)里的數(shù)據(jù)匹配，最后Server 軟件在數(shù)據(jù)庫(kù)中匹配到的用戶(hù)的事務(wù)信息將通過(guò)搭建好的Mosquitto 服務(wù)器推送到手機(jī)端，如圖7所示。

圖7 數(shù)據(jù)流傳輸過(guò)程

根據(jù)數(shù)據(jù)傳輸過(guò)程，最終待辦事務(wù)消息的傳輸結(jié)果如圖8所示。

圖8 手機(jī)端APP 接收到消息

4 結(jié) 論

項(xiàng)目開(kāi)發(fā)了與人臉識(shí)別硬件設(shè)備對(duì)接的程序，并將人臉識(shí)別數(shù)據(jù)編號(hào)提取后發(fā)送至自研服務(wù)端，由服務(wù)端查找數(shù)據(jù)庫(kù)中指定人臉的事務(wù)消息后將數(shù)據(jù)發(fā)送至MQTT 服務(wù)端完成數(shù)據(jù)的發(fā)布。手機(jī)端是接收數(shù)據(jù)的載體，向MQTT 服務(wù)端訂閱隸屬自己人臉I(yè)D 的事務(wù)消息，在進(jìn)行門(mén)禁進(jìn)入時(shí)，由MQTT 服務(wù)端實(shí)時(shí)推送至手機(jī)端。作品將人臉識(shí)別設(shè)備、網(wǎng)絡(luò)數(shù)據(jù)接收處理、事務(wù)消息存儲(chǔ)、MQTT 輕量級(jí)推送等功能通過(guò)開(kāi)發(fā)集成至一體化作品，完成門(mén)禁通過(guò)時(shí)系統(tǒng)中關(guān)于通過(guò)人員事務(wù)消息的推送。項(xiàng)目來(lái)源于應(yīng)用單位實(shí)際需求，主要的應(yīng)用范圍如下：

（1）服務(wù)于日常需處理事務(wù)消息的工作人員，如職員、教師等。當(dāng)前的通知方式大多都是通過(guò)群聊設(shè)置群公告或者@全體成員來(lái)實(shí)現(xiàn)，而當(dāng)消息越來(lái)越多時(shí)，工作人員就很有可能遺忘其中一些消息，對(duì)此，本項(xiàng)目致力于實(shí)現(xiàn)用戶(hù)在進(jìn)出單位后第一時(shí)間收到代辦事項(xiàng)的消息推送的功能。

（2）服務(wù)于日常需發(fā)布事務(wù)消息的管理人員，如負(fù)責(zé)人，主任等。傳統(tǒng)的事務(wù)消息通知需要管理人員對(duì)不同的事務(wù)消息進(jìn)行單獨(dú)或者集體通知，并需要確定成員是否收到，這些工作重復(fù)度高，耗費(fèi)大量時(shí)間。而本項(xiàng)目的事務(wù)消息推送系統(tǒng)提供了一個(gè)線(xiàn)上管理事務(wù)消息推送的方式，管理人員在電腦端即可發(fā)布所有消息，不必逐個(gè)通知和確認(rèn)。