校园-智慧门禁(卡码脸)解决方案

发布时间:2024年01月07日

?前言

入职新公司也已经一年有余,入职后主要从事的是门禁项目,公司设计的项目是偏saas化的智慧门禁系统,目前已经在多所大学上线,以下是对该项目的个人总结复盘。

一、系统主要功能和扩展功能

  • 可实现学校统一门禁设备管理
  • 可实现人员管理,人员可通行场所管理(宿舍楼,食堂,图书馆)
  • 记录下学生的通行信息,可供大数据分析,例如宿管系统,可提供学生归宿情况。
  • 第三方平台支持功能,例如学生预约几点到几点图书馆,图书馆门禁设备自动开启

二、实现方案

1.开门方式

扫脸开门。(我们是用的本地鉴权,名单是写进设备本地人脸库的,线上门禁系统down机也不影响客户使用)

面板机选品注意事项。

  • 识别成功率,这也是我们关心的最重要的。建议还是测试一下在阳光下、下雨环境、阴天、晚上等多情境。
  • 设备的兼容性,设备控制可闸机的闸机类型有哪些。
  • 支持和第三方系统对接,而不是单纯的使用厂家提供的一个面板机管理界面,类似写死在机器中的一个路由器界面。
  • 功能方面。
    • 设备可支持策略模式,例如哪些人每周一可进、周二不可进等个性化功能,部分学校有这个需求。
    • 设备支持测温功能、增加广告等等,具体看客户需求。
  • 技术方面。
    • 如果提供类似服务包的,要咨询服务包的并发量。
    • 设备是否支持覆盖去新增人员,没有的话我们对接起来如果想去修改照片,只能先删除在新增,但是我们和设备异步通信,你编码难度会提高很多,等待删除成功的通知,再去下发人员。
  • 面板机品牌1:巨龙创视

?对接协议:http协议。厂家提供一个服务包,服务包和现场面板机进行通信,门禁系统可以直接和厂家提供的服务包进行通信。(猜测可能觉得让客户对接mqtt协议比较困难,提供了一个较为简单版本的http协议包对接)

API接口列表(部分):

对接缺点:

1. 由于所有的设备共享一个服务包,开学高峰期下发人员并发高,服务包并发非常严重,导致门禁系统和服务包交互大量超时,由于服务包厂家提供,其中此服务包对门禁系统提供http协议接口,对设备通信猜测使用的是UDP通信,我们这边也不好对服务包做集群处理,后续改为单线程下发人员,导致下发人员速度非常慢。

2. 对接是base64流传递给服务包,服务包传递给设备下发人员,可想而知,设备是不支持批量下发的,流批量汇聚太大了,我们的门禁系统也会内存溢出。

  • 面板机品牌2:海清面板机

对接协议:mqtt协议。

API接口列表(部分):

对接优点:

该设备支持传递URL下发,意味着可支持批量下发。

对接缺点:mqtt协议对接设备有一个很大的缺点,下发名单的时候不支持并发操作,可能你下发人员过程中会给你反馈设备繁忙中,厂家文档中对此表示,建议下发人员之前查询下当前指令是否执行完成,或者当前设备状态,建议批量下发人员。我们下发人员过程要的就是一个最终一致性,所以我们在编码方面就十分苛刻。

方案1:下发人员名单首先都会进入到一个队列中去,每次进行完一个命令,根据名单数量预估下发时间进行阻塞,在执行下一条指令。

方案2:下发人员名单首先都会进入到一个队列中去,每次进行完一个命令,等待上一条执行执行完成设备通知你,在进行下一条指令执行,注意等待的超时时长。

扫码开门

公司自有嵌入式开发工程师,其原理也非常简单,网购一台二维码门禁读头,和嵌入式开发工程师沟通,我们在最开始会往设备中写入一个序列号在第几位,当用户打开自己的二维码时,我们会往二维码中写入是否可以开启闸机。例如序列号是2,0代表不可以开门,1代表可以,用户二维码内容是01,可以开闸机,10不可以,当然我们为了安全考虑,其中还加了二维码加密等内容。

这是我们目前使用过程中最方面的一种开门方式,对云端的依赖程度非常高,二维码需要实时去生成,

刷卡开门

刷卡开门也是使用二维码门禁读头,将十二进制8位卡内码下进读头中,实现本地鉴权。

PS:其实面板机也有这个功能,至于为什么单独增加此设备,估计是为了问学校单独增加设备增加sh。

2.安装注意事项

1.? 再给设备分配IP的时候,一定要分配静态IP,提前把网络环境都搞好,防止后期IP冲突的情况。

2.? 面板机调试一些忽略点。

  • 安装注意人脸的扫描距离,防止出现距离2m以外,路过就能开门,还有就是站在两台面板机中间,两个通道都开门的情况。
  • 注意面板机的时间问题,面板机一般都带此功能,网络计时。
  • 调整面板机下发名单后,要测试能够正常的开门,无权限进行,白名单通行,防止接线错误。
  • 注意厂家发送的面板机版本问题,不同面板机可能会出现协议不同。

文章来源:https://blog.csdn.net/whiteWYC/article/details/135186813
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。