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 自定義協議驅動開發指導》文檔。