3.1 门禁控制器对接方案介绍
1．概述
1.1 编写目的
用于指导人行设备厂家的技术人员，基于自定义协议进行方案评估和开发工作，从而实现人行设备接入。目前自定义协议的人行设备主要是刷卡门禁控制器。本文档同时指导自定义协议驱动的开发流程。
1.2名词解释
名词 | 解释 |
Link IoT Edge | 物联网边缘计算产品（Link IoT Edge，简称LE），即阿里云物联网平台（IoT）中的边缘计算产品。提供安全可靠的数据计算能力，可供本地处理设备数据，减少上传云端的成本。 |
网关 | 运行Link IoT Edge软件的计算设备统称为边缘网关或边缘服务器，简称网关。 |
子设备 | 指通过一定的协议或接口接入到Link IoT Edge网关上的设备（即设备接入到网关后称为子设备），网关代理该子设备与云端进行通信。 |
驱动 | Link IoT Edge中的设备接入模块称为驱动（driver）或设备接入驱动。所有连接到Link IoT Edge的设备都需要通过驱动实现接入。 |
2．系统架构图
图解说明：
①云端：即云平台以及使用人行应用和中台服务接口开发的上层应用软件，应用软件运行在PC或移动设备上，进行卡号查询及权限更新等操作。
②边缘网关：运行LE组件及人行边缘应用，LE组件内运行自定义协议驱动，驱动内包含设备接入SDK（LEDA）和开发者实现两个部分。驱动负责设备的连接管理、事件上报及服务调用。
③设备端：即门禁控制器和读卡器等硬件设备。设备供应商应提供设备通信协议或设备访问SDK，供驱动访问或控制设备使用。设备供应商还应提供硬件配置工具，可以进行设备初始化、设备参数配置及故障定位等功能。
3．交互流程
3.1 刷卡门禁控制器
3.1.1 卡号同步流程
3.1.2 刷卡流程
4．对接流程
4.1 明确项目分工
根据系统架构图的内容，理解自定义协议驱动所处的位置。
明确各环节项目分工——需要设备端技术人员和协议驱动开发人员明确各自负责内容。
明确自定义协议驱动需要实现的功能，参考对应设备的物模型（刷卡门禁设备请参考《3.3 人行设备物模型-Rev0.1》文档的“第3章【智慧社区-人员通行-刷卡门禁】”物模型介绍。）。
明确自定义协议驱动与设备的通信方式，需要设备厂商提供设备端SDK，使自定义协议驱动可以基于该SDK实现访问设备数据和下发控制命令的功能。
4.2 信息收集
刷卡门禁设备信息：
提供设备的硬件型号、设备ID、设备IP及端口号
提供用于调试的卡号
射频卡读取时间
是否支持手机NFC
手机NFC读取时间
设备保存卡权限的时间
4.3 驱动开发及自测
参考《3.2 自定义协议驱动开发指导》文档，了解物联网设备接入，熟悉LEDA接口，熟悉实现驱动的基本方式，开发自定义协议驱动。
自定义协议驱动需通过驱动日志确认设备向云平台注册上线的接口被调用，并保证设备持续稳定地处于在线状态。
自定义协议驱动需通过驱动日志确认设备上报事件的接口被调用，通过驱动日志确认服务方法接口被调用。
4.3.1 驱动命名规则
在物联网应用服务平台，新创建的驱动英文名称定义有下面的规范建议：
驱动名称包含内容：
厂商名称_厂商产品型号_适用领域_驱动功能
如果这个驱动是通用驱动，适用所有厂商，则驱动名称里可以去掉厂商名称和厂商产品型号；
如果这个驱动支持某个厂商的所有产品型号，则驱动名称里可以去掉厂商产品型号。
适用领域说明：
人行：PerAccess（personal access）
车行：VehAccess（vehicle access）
EBA：EBA
安防：SecSystem（security system）
驱动功能说明：
例如EBA领域，Modbus功能，例如人行领域，可视对讲功能。
驱动名称使用大驼峰命名规范，即每个单词的首字母都要求是大写
举例说明：
一个驱动，可以支持能效通公司的所有型号的EBA Modbus设备，驱动名称可定义为：Nxtone_EBA_Modbus
4.4 测试验收
设备厂商按照技术对接要求完成开发后，厂商需要使用智慧社区设备认证实验室准入测试的测试用例进行测试，并满足通过标准。测试用例请参见附件：《人行测试用例》
厂商的设备通过智慧社区实验室准入测试后，需要设备寄送给智慧社区设备认证实验室进行测试认证。通过该认证后，厂商的设备则可以在项目中落地使用
5. 驱动开发
请参考《3.2 自定义协议驱动开发指导》文档。