1 引言

　　電梯物聯網在國內的應用發展經歷了多個階段，從最初的電梯狀態監視、基本信息查詢，到電梯故障困人的應急救援，再到按需維護、智慧電梯。應用場景越來越深入，對電梯行業的貢獻也不斷增大，電梯制造企業、電梯維保企業、電梯部件企業、電梯使用方及政府監管部門等都已享受到電梯物聯網帶來的好處。隨著電梯物聯網發展的深入，統一管理和標準化工作顯得尤為重要。各個企業紛紛建立企業級別的電梯物聯網平臺，管理本單位旗下的電梯。各地政府也逐漸開始搭建監管平臺，管理本地區管轄范圍內的電梯。部分地方已經出臺電梯物聯網技術規范和監管平臺對接接口標準要求，為電梯物聯網的健康發展、規范化發展打下了堅實的基礎。但不同的地方政府制定的監管對接接口標準要求不盡相同，接口類型、編碼格式、安全性保證、數據格式等存在一定的區別，需要從實際應用的角度去進一步規范和優化對接接口，為后續其他地方建立監管平臺時提供參考依據。

　　2 監管平臺數據接口研究

　　2.1 各地物聯網監管平臺數據接口參數比較

　　目前已經建立監管平臺并制定對接標準的地方及其標準名稱如下：

　　(1) 福建，龍巖，《電梯救援公共平臺第三方接入標準協議》

　　(2) 廣東，深圳，SZDBZ-116-2014《電梯運行監測系統技術規范》

　　(3)江蘇，無錫，《電梯平臺與服務接口協議

　　(HTTP方式)V4.0》

　　(4)遼寧，沈陽，《和平區政府對接要求》

　　(5)陜西，西安，《DB6101T 3006—2019 電梯物聯網運行監測系統技術規范》

　　(6)上海，《一體化智慧電梯專業管理服務平臺遠程監測系統數據交互規范_v1.1》

　　(7)浙江，湖州，《特種設備應用平臺API文檔-電梯V1.5》

　　(8)浙江，金華，《電梯安全運行監測系統技術規范V2.0》

　　(9)浙江，寧波，《電梯物聯網政府平臺數據接口》

　　(10)浙江，溫州，《電梯智能化監測裝置系統技術規范》

　　表1從傳輸協議、編碼格式、參數格式、音視頻流協議等角度對各個地方已制定標準進行了對比。

表 1 各地電梯物聯網監管平臺接口參數對比

　　2.2 各地物聯網監管平臺數據接口數據內容

　　(1)電梯基礎信息

　　包含了：電梯注冊代碼、電梯制造單位、電梯類別、型號、出廠日期、出廠編號、安裝地址(部分地方還記錄了電梯所在位置經緯度信息)、內部名稱(編號)、安裝單位、安裝日期、應急救援電話、維保單位名稱、維保單位組織機構代碼、維保單位負責人、維保單位應急救援電話、上次維保日期、產權單位、使用單位名稱、使用單位負責人、使用單位電話、使用單位組織機構代碼、行政區域代碼、電梯使用狀態、使用場合、使用地點、注冊登記日期、投用日期、檢驗機構名稱、監察單位、上次檢驗日期、上次檢驗結果、下次檢驗日期、物理樓層(直梯)、停靠站數(直梯)、額定速度、額定載荷(直梯)、理論輸送能力、提升高度(扶梯)、傾斜角(扶梯)、名義寬度(扶梯)、數據更新時間。

　　(2)電梯運行實時數據

　　包含了：電梯注冊碼(存量梯)、制造單位統一社會信用代碼(新裝梯)、出廠編號(新裝梯)、當前服務模式-扶梯/直梯(停止服務、正常運行、檢修、消防返回、消防員運行、應急電源運行、地震模式、未知)、當前服務模式- 扶梯( 停止運行、正常運行、檢修、未知)、運行狀態-扶梯/直梯(停止、運行)、運行方向-扶梯/直梯( 無方向、上行、下行)、運行方向- 扶梯( 節能停止運行、名義速度上行、節能減速上行、名義速度下行、節能速度下行)、開鎖區域- 直梯( 轎廂在開鎖區域、轎廂在非開鎖區域)、電梯當前樓層-直梯、轎內是否有人-直梯(有人、無人)、關門是否到位(關門到位、無關門到位信號)、機房溫度-直梯、機房門開關-直梯、轎門狀態-直梯(未知、正在關門、關門到位、正在開門、開門到位、門鎖鎖止、保持不安全關閉狀態)、廳門狀態-直梯(門鎖鎖止、無門鎖鎖止信號)、轎廂超載- 直梯( 超載、未超載; 未知、正常、滿載、超載)、曳引機狀態- 直梯( 待機、曳引機制動器提起、曳引機制動器釋放)、人臉識別實時人數-直梯、乘梯人行為模式-直梯(正常、不文明行為、危險行為)、轎廂當前負載、累計運行次數、累計運行時間、底坑濕度、物聯網監測裝置電壓、物聯網監測裝置供電電源信息(自帶電源、外接電源)、電池信息、監測裝置入網登記編號、綜合故障信號、詳細故障代碼、內召信號、實時視頻訪問鏈接、實時語音訪問鏈接、開門按鈕信號、運行速度、是否停電(未知、停電、有電)、自學習運行狀態(未知、正常、返基站、就近返平層)、采樣時間。

　　(3)電梯統計數據

　　包含了：電梯注冊碼(存量梯)、制造單位統一社會信用代碼(新裝梯)、出廠編號(新裝梯)、接入平臺電梯總共數量、電梯在線數量、設備開門次數、設備累計開關門次數、能耗統計、設備累計運行時間、設備累計運行次數、設備鋼絲繩(帶)折彎次數、設備累計運行距離、乘梯人數、采樣時間。

　　(4)故障報警數據

　　包含了：時間戳(精確到秒)、電梯注冊代碼、電梯設備編號、監測裝置編號、數據生成時間(設備當前時間)、事件來源、發生時間、故障代碼、故障原因初步判斷、告警內容、是否困人(困人、非困人)、困人開始時間、接警類型(未知、自動、人工)、救援聯系人、救援聯系人電話、救援單位、報警電話接通時間、被困乘客人數、救援單位、有無人員傷亡、受傷人數、死亡人數、是否通知120、通知120時間、是否解救成功、當前救援狀態(初始上報、啟動救援、達到現場、救援完成)、救援人員位置經緯度坐標、救援人員到達時間、救援完成時間、維保單位接警時間、派遣的維修人員、維修完成時間、故障處理是否結束狀態標志、電梯速度、門開關狀態(開、關)、電梯運行方式(電梯電鎖、電梯檢修、電梯消防、電梯司機、電梯自動、電梯專用、電梯井道自學習、滿載、超載、其他)、故障樓層、電源狀態(正常、異常)、運行方向(下行、上行、停止)、當前故障狀態、故障恢復時間、視頻流地址、狀態(新增、清除)。

　　(5)電梯維保信息數據

　　包含了：電梯設備代碼、電梯設備編號、檢查裝置編號、維保單ID、維保狀態(未開始、已開始、完成、關閉)、維保周期(半月、季度、半年、年度)、維保單位信用代碼、維保單位、負責維保人員、負責維保人員電話、維保日期、是否發生修理、修理內容、開始時間、結束時間、備注。

　　(6)電梯事件數據

　　包含了：廠家編號、外設編號、電梯注冊代碼、事件代碼、事件發生時間、事件開始時間、事件結束時間、過程記錄列表( 過程記錄編號、發生時間、過程記錄內容)、語音文件列表( 語音文件編號、語音對講發生時間、訪問語音文件鏈接地址)、視頻文件列表(視頻文件編號、視頻文件發生時間、視頻錄制位置(轎廂、機房、轎頂)、訪問視頻文件鏈接地址)、事件內容描述、電梯恢復自動運行模式( 未恢復、恢復)、主電源斷電( 未斷電、斷電)、停止服務( 未停止、停止服務)、檢修模式( 未進入、已進入)、消防返回模式( 未進入、已進入)、消防員運行( 未進入、已進入)、應急電源運行( 未進入、已進入)、地震運行模式( 未進入、已進入)、其他事件代碼。

　　(7)監測終端設備數據

　　包含了：電梯設備代碼、電梯設備編號、監測裝置編號、設備在線狀態(未知、下線、在線)、狀態類型(監測裝置、攝像頭、未知、其他)、上下線時間、其他、在線率、采集設備發送時間戳、平臺發送時間戳。

　　(8)音視頻數據

　　包含了：電梯注冊碼、視頻流URL、接口過期時間、告警編號、語音對講服務器地址、設備序列號、信令服務器地址、信令服務器端口、穿網服務器地址、穿網服務器端口、WSS端口、被叫賬戶、主叫賬戶、主叫賬戶的密 碼 。

 2.3各地物聯網監管平臺數據接口安全性和可實現性對比

各地接口關于安全的解決方案基本上都是采用Token 令牌，接入方通過線下的方式向平臺供應商申請Appkey和AppSecret，接入方需保存好Appkey和AppSecret，一旦泄露，需要重新申請。

　　接入方在調用平臺接口之前需要通過給定的Appkey 和AppSecret獲取Token令牌，然后利用Token去訪問對應的接口。Token一般都會設置有效期，但一般沒有最佳方案，需要具體問題具體分析。

　　Token令牌能夠加提高接口安全性，限制非授權方訪問數據，在一定程度上能夠保障數據安全。Token令牌是非常成熟的解決方案，因其簡單易用的特性，得到大部分開發者的認可，并使用在一些安全數據不是那么高的系統中。Token令牌雖然有很多優點，但缺陷也比較明顯，尤其是在一定程度上增加了對接的難度，同時，因為在獲取Token時需要用到Appkey和AppSecret，這無形中增加了數據被盜取的風險。所以現在關于API安全解決方案中，部分已經摒棄了Token令牌的方式，而是采用簽名方式。簽名的方式可以避免在網絡上傳輸AppSecret，同時無需處理Token過期的問題。

　　2.4 研究結論

　　(1)通過各地平臺接口對接方式的比較，基本上都采用Restful風格的接口。但Restful風格的api并不適合實時數據的傳輸，建議采用websocket方式。

　　(2)各地差異最大的部分在于各項數據的內容，例如：電梯檔案、實時數據等，各地字段差異非常大，建議從按需維保角度反推信號需求。

　　(3)數據安全。除建議認證方式升級外，更應該考慮https協議。

　　結束語

　　按需維保和智慧電梯的實現離不開電梯物聯網，本文在研究多個地方已建電梯監管平臺的基礎上，綜合對比多項技術指標，包括接口類型、接口安全性、數據編碼格式、參數格式及音視頻流協議等，得出監管平臺接口的優化建議，為電梯行業其他尚未建立監管平臺的地方提供參考。