南京電梯安全運行監(jiān)控系統(tǒng)技術(shù)規(guī)范

1、南京市電梯平安運行監(jiān)控系統(tǒng)技術(shù)標準傳感與通訊技術(shù)南京市特種設(shè)備平安監(jiān)督檢驗研究院1 范圍本標準規(guī)定了電梯平安運行監(jiān)控系統(tǒng)中的傳感與通訊相關(guān)的功能及性能要求、平安性要求、數(shù)據(jù)通 訊、信息傳輸、監(jiān)視及報告等技術(shù)要求。本標準適用于電梯公共平安領(lǐng)域的監(jiān)控，其他領(lǐng)域的監(jiān)控系統(tǒng)也可以參考采用。2 標準性引用文件以下文件中的條款通過本標準的引用而成為本標準的條款。但凡注日期的引用文件，其隨后所有的 修改單不包括勘誤的內(nèi)容或修訂版均不適用于本標準，然而，鼓勵根據(jù)本標準達成協(xié)議的各方研究 是否可使用這些文件的最新版本。但凡不注日期的引用文件，其最新版本包括所有的修改單適用于 本標準。GB/T 7024 - 20

2、21電梯、自動扶梯、自動人行道術(shù)語GB 7588 - 2003電梯制造與安裝平安標準GB 21240 - 2007液壓電梯制造與安裝平安標準GB/T 2887-2002 電子計算機場地通用標準GB/T 17799.1-1999 電磁兼容 通用標準 居住、商業(yè)和輕工業(yè)環(huán)境中GB/T 17799.3-2001 電磁兼容通用標準居住商業(yè)和輕工業(yè)環(huán)境中的發(fā)射標準GB50348-2004 平安防范工程技術(shù)標準GA/T 367-2001 視頻安防監(jiān)控系統(tǒng)技術(shù)要求3 術(shù)語和定義GB/T 7024 - 2021、GB7588 - 2003、GB21240 - 2007確定的以及以下術(shù)語和定義適用于本標準。3.

3、1 電梯平安運行監(jiān)控網(wǎng)絡(luò) Elevator public safety monitoring network以保障電梯平安為目的，綜合運用平安防范、通信、計算機網(wǎng)絡(luò)、嵌入式技術(shù)、傳感技術(shù)、系統(tǒng)集 成技術(shù)，在城市范圍內(nèi)建立具有信息采集、傳輸、控制、顯示、存儲、處理等功能的能夠?qū)崿F(xiàn)電梯故障 診斷、故障報警、應(yīng)急救援、視頻監(jiān)控、語音安撫等的平安監(jiān)控網(wǎng)絡(luò)。利用該系統(tǒng)，可對城市范圍內(nèi)的 電梯實施有效的平安監(jiān)控及應(yīng)急處置，并可為電梯應(yīng)急救援體系建設(shè)提供相應(yīng)的平臺。3.2 電梯傳感裝置 elevator sensing equipment應(yīng)用于電梯可監(jiān)測電梯運行狀態(tài)信息、具有視頻信號采集，能建立語音通訊，具

4、有信號采集、處理、 信息存儲、傳輸和平安控制功能的裝置。3.3 困人 people trapped電梯因故障如門鎖回路或平安回路斷開，控制系統(tǒng)失靈或誤動作、供電系統(tǒng)停電以及人為等原 因，使正常行駛的電梯突然停駛，從而將乘客困在轎廂內(nèi)的現(xiàn)象。3.4 報警 alarm對GB7588 - 2003和GB21240-2007中規(guī)定的緊急報警裝置操作的監(jiān)視。3.5 故障 fault可能影響和中斷設(shè)備正常運行的狀態(tài)。3.6 設(shè)備 installation一臺電梯。4. 技術(shù)要求4.1 一般要求系統(tǒng)應(yīng)符合本標準的規(guī)定，系統(tǒng)中的設(shè)備應(yīng)符合有關(guān)標準和各自企業(yè)產(chǎn)品標準的規(guī)定，并按照規(guī)定 程序批準的圖樣及文件制造和

5、成套。4.2 環(huán)境條件4.2.1 系統(tǒng)中用于機房、調(diào)度室的設(shè)備，應(yīng)能在以下條件下正常工作：a) 環(huán)境濕度：-5-40 C；b) 運行地點的最濕月，月平均最高相對濕度為90%，同時該月月平均最低溫度不高于25C；c) 溫度變化率：小于10C /h,且不得結(jié)露；d) GB/T 2887 規(guī)定的塵埃、照明、噪聲、電磁場干擾和接地的條件。4.2.2 除有關(guān)標準另有規(guī)定外,系統(tǒng)中用于現(xiàn)場的設(shè)備應(yīng)在以下條件下正常工作：a) 環(huán)境溫度： -2070 C ；b) 平均相對濕度：不大于 95%(+25C )c) 大氣壓力： 80106kPa。4.3 供電電源4.3.1 監(jiān)控系統(tǒng)交流電源a) 額定電壓： 380V

6、/220V ,允許偏差± 7%；b) 諧波：不大于 5%；c) 頻率：50Hz,允許偏差土 5%4.3.2 前端設(shè)備交流電源a) 額定電壓：220V，允許偏差土 10% ;b) 諧波：不大于 5%；c) 頻率：50Hz,允許偏差土 5%。4.4 電磁兼容性要求4.4.1 設(shè)備抗擾度要求對設(shè)備進行靜電放電、射頻電磁場輻射、電快速瞬變脈沖群、射頻場感應(yīng)的傳導(dǎo)騷擾以及電壓暫降、 短時中斷和電壓變化的 6項抗擾度試驗,設(shè)備的抗擾度性能應(yīng)滿足GB/T 17799.1- 1999中的表1、表2和表4中規(guī)定限制的要求。4.4.2 設(shè)備發(fā)射要求設(shè)備的輻射和傳導(dǎo)發(fā)射值應(yīng)符合 GB/T 17799.3-

7、2001 中設(shè)定限值的要求。443監(jiān)控系統(tǒng)的抗電磁干擾性應(yīng)能滿足GA/T 367-2001中的要求，傳輸線路的抗干擾設(shè)計應(yīng)符合GB50348-2004中的規(guī)定，系統(tǒng)電磁輻射防護性能應(yīng)滿足GA/T 367-2001中的要求。4.5平安性要求電源線電源(A.C)引出線必須使用三芯電源線，其中地線必須與設(shè)備的保護接地端連接牢固，其接地電阻不 應(yīng)大于0.5Q，并能承受19.6N的拉力60s不損傷和脫落。絕緣電阻電源(A.C)引入端子與外殼裸露金屬部件之間的絕緣電阻在正常條件下應(yīng)?100M Q，溫熱條件下> 10M Q。抗電強度設(shè)備電源插頭或電源引入端與外殼裸露金屬部件之間，應(yīng)能承受試驗電壓1.5

8、KV、45Hz 65Hz交流電或相當交流峰值的直流電壓歷時1min的抗電強度試驗，應(yīng)無擊穿和飛弧現(xiàn)象。泄漏電流應(yīng)不大于5mA(A.C峰值)。穩(wěn)定性要求設(shè)備在正常工作條件下，連續(xù)工作168h，不應(yīng)出現(xiàn)電、機械或操作系統(tǒng)的故障。4.5.6 可靠性要求本標準采用平均無故障工作時間(MTBF)衡量產(chǎn)品的可靠性要求。設(shè)備在正常氣候條件下的平均無故障工作時間(MTBF)應(yīng)不小于4000h。5系統(tǒng)功能及性能要求5.1功能5.1.1 網(wǎng)絡(luò)模型系統(tǒng)網(wǎng)絡(luò)模型如圖1所示：電梯平安運行監(jiān)控網(wǎng)絡(luò) 電梯傳感裝置圖1系統(tǒng)網(wǎng)絡(luò)模型數(shù)據(jù)采集電梯傳感裝置必須能夠通過相應(yīng)傳感器采集到包括電梯總接觸器狀態(tài)、運行接觸器狀態(tài)、平安回路

9、狀態(tài)、運行狀態(tài)、門狀態(tài)、轎廂狀態(tài)、平層狀態(tài)、上極限狀態(tài)、下極限狀態(tài)、報警按鈕狀態(tài)等電梯的狀 態(tài)信號；必須能夠及時檢測到困人時間；必須能夠及時判斷包括平安回路短路、轎廂沖頂、蹲底、轎廂 開門走梯、運行超時、反復(fù)開關(guān)門、長時間開門、轎廂在非平層區(qū)域停止、轎廂報警按鈕動作等故障。具體見附錄 A 代碼表。5.1.3 緊急通話5.1.3.1 主動呼叫功能 電梯傳感裝置應(yīng)具有語音通訊功能，并預(yù)設(shè)緊急通話號碼。通話裝置應(yīng)該安裝在轎廂內(nèi)明顯的位置，照度滿足GB7588 - 2003要求。5.1.3.2 應(yīng)答功能電梯傳感裝置應(yīng)有自己的唯一的終端號碼，電梯平安運行監(jiān)控網(wǎng)絡(luò)可通過呼叫終端號碼，并在5秒內(nèi)自動建立語音

10、鏈路。5.1.4 視頻監(jiān)控 具有轎廂視頻信號采集功能的電梯傳感裝置，應(yīng)可通過有線或無線網(wǎng)絡(luò)的形式將數(shù)字視頻信號實時傳輸至電梯平安運行監(jiān)控網(wǎng)絡(luò)。5.2 性能要求5.2.1 如果GB7588 - 2003和GB21240 - 2007中指定的緊急報警裝置的信號通過電梯傳感裝置通信，那么 報警功能傳輸能力在斷電后應(yīng)至少保持 1h。5.2.2 電梯傳感裝置應(yīng)在外接電源斷電的情況下，至少保證正常運行1h。5.2.3 電梯傳感裝置應(yīng)具有內(nèi)部供電裝置為時鐘供電，保證在外部斷電后，時鐘正常工作。5.2.4 電梯傳感裝置應(yīng)符合GB7588-2003中指定的平安規(guī)那么，電梯傳感裝置的安裝、工作、數(shù)據(jù)傳輸及 設(shè)備故

11、障等各種情況均不能削弱、干擾電梯控制系統(tǒng)信號，阻礙電梯正常運行。6 數(shù)據(jù)通訊6.1 數(shù)據(jù)通訊模塊應(yīng)支持 RS-232/RS-422/RS-485/TTL數(shù)據(jù)傳輸協(xié)議，支持 30057600 bits/s的傳輸速率，同時支持1個或多個冗余通訊接口，傳輸?shù)碾娞葸\行狀態(tài)和電梯故障數(shù)據(jù)格式應(yīng)滿足附錄B的數(shù)據(jù)格式要求。6.2 數(shù)據(jù)通訊中的語音傳輸應(yīng)支持通話或緊急呼叫、支持全速率，增強全速率和半速率、 支持QCELP 13k音頻編解碼、支持回聲抑制和噪聲消除功能、支持雙音多頻 (DTMF) 。6.3 數(shù)據(jù)傳輸支持IS 707數(shù)據(jù)業(yè)務(wù)，支持153kbps的包數(shù)據(jù)速率，支持Class 2.0 Group 3

12、，碼分多址擴 頻機制，符合IS-95A、IS-95B空中接口標準。6.4 監(jiān)控網(wǎng)絡(luò)平臺和終端直接的數(shù)據(jù)傳輸需要同時支持SMS、UDP和TCP三種承載方式。無論使用短信、 TCP 還是 UDP 傳輸，不影響監(jiān)控網(wǎng)絡(luò)平臺與終端的交互過程。 對于終端和監(jiān)控網(wǎng)絡(luò)平臺的數(shù)據(jù)連接， 終端要么一直使用 TCP，要么一直使用UDP。6.5 電梯傳感裝置與電梯平安運行監(jiān)控網(wǎng)絡(luò)的接口協(xié)議應(yīng)滿足附錄C中規(guī)定的數(shù)據(jù)采集終端與平臺接口協(xié)議。6.6 數(shù)據(jù)通訊模塊供電電壓 +5V+26VDC，紋波300mV，待機時功耗為80mA+5VDC , 30mA+12VDC ，數(shù)據(jù)傳輸時功耗為： 260mA+5VDC ， 110mA

13、 +12VDC 。7 信息傳輸要求7.1 電梯傳感裝置宜與電梯平安運行監(jiān)控網(wǎng)絡(luò)建立穩(wěn)定的數(shù)據(jù)鏈路，并上傳電梯運行狀態(tài)數(shù)據(jù)，運行狀 態(tài)數(shù)據(jù)的傳輸周期不低于 2s,應(yīng)符合附錄B的要求。7.2 電梯發(fā)生故障時，電梯傳感裝置必須實時將故障數(shù)據(jù)連同故障發(fā)生時間、運行狀態(tài)數(shù)據(jù)上報電梯安 全運行監(jiān)控網(wǎng)絡(luò)，并確保傳輸有效。如果故障持續(xù)，應(yīng)以 10-15min 周期進行傳輸，直至故障去除。電梯 故障應(yīng)符合附錄B的要求。7.3 電梯傳感裝置須響應(yīng)電梯平安監(jiān)控網(wǎng)絡(luò)的鏈接請求，以不低于1s的周期傳輸電梯運行狀態(tài)數(shù)據(jù)。7.4 電梯運行狀態(tài)和故障狀態(tài)記錄的時間和日期應(yīng)以電梯傳感裝置的內(nèi)部時鐘為基準。7.5 如果電梯傳感裝

14、置不能保持通信鏈接時， 應(yīng)至少保存最近十條故障記錄及故障發(fā)生時的運行狀態(tài)數(shù) 據(jù)。7.6 如果在讀取數(shù)據(jù)過程中發(fā)生故障或報警，那么困人事故優(yōu)先于故障、報警和狀態(tài)。8 監(jiān)視及報告8.1 電梯傳感裝置及所有與設(shè)備相關(guān)的裝置須經(jīng)過具有特種設(shè)備檢驗核準資質(zhì)的綜合檢驗機構(gòu)測試且 取得合格的驗收報告方可接入電梯平安運行監(jiān)控網(wǎng)絡(luò)并投入使用。8.2 電梯傳感裝置中可安裝在井道、機房內(nèi)和或機房外。8.3 電梯傳感裝置應(yīng)能與一個或多個遠程點進行通信。8.4 應(yīng)提供平安系統(tǒng)，例如密碼，以控制通信鏈接。附錄A標準性附錄代碼表表A.1電梯狀態(tài)代碼代碼狀態(tài)說明0001電梯總接觸器狀態(tài)總接觸器吸合0002電梯運行接觸器狀態(tài)運

15、行接觸器吸合0003電梯平安回路狀態(tài)平安回路正常0004電梯運行狀態(tài)電梯處于正常運行狀態(tài)非檢修狀態(tài)0005電梯門狀態(tài)電梯門關(guān)閉0006轎廂狀態(tài)電梯上行0007轎廂狀態(tài)電梯下行0008電梯平層狀態(tài)電梯平層0009電梯上極限狀態(tài)電梯上極限動作000A電梯下極限狀態(tài)電梯下極限動作000B轎廂報警按鈕動作電梯發(fā)生故障時報警表A.2電梯困人代碼代碼事件說明4001轎廂困人電梯發(fā)生故障時發(fā)生困人表A.3電梯故障代碼代碼故障說明4002平安回路斷路任何平安開關(guān)斷開例如：急停、極限等4003轎廂沖頂電梯正常運行時上極限開關(guān)動作4004轎廂蹲底電梯正常運行時下極限開關(guān)動作4005轎廂開門走梯4006運行超時一次

16、運行時間超過標準和設(shè)計規(guī)定的時間4007反復(fù)開關(guān)門根據(jù)法規(guī)規(guī)定的開關(guān)門時間判斷開關(guān)門的頻率是否超限4008長時間開門轎廂門在規(guī)定的時間內(nèi)不關(guān)門4009轎廂在非平層區(qū)域停止400A轎廂報警按鈕動作電梯發(fā)生故障時報警400B保存400C保存附錄B標準性附錄數(shù)據(jù)格式B.1電梯運行狀態(tài)數(shù)據(jù)包25個字節(jié):表B.1電梯運行狀態(tài)數(shù)據(jù)包格式表 B.10123包頭狀態(tài)消息代碼終端代碼Byte24Byte23Byte22Byte21Byte20Byte19Byte18Byte17Byte16EFAE0x02303930393039303930393039-0x02:狀態(tài)0x04:故障ASCII 碼09ASCII

17、碼09ASCII 碼09ASCII 碼09ASCII 碼09ASCII 碼09表 B.11 續(xù)表 B.1045樓層信息電梯狀態(tài)位Byte15Byte14Byte13Byte12BytellByte10Byte95F/2B303930390x00/0x010x00/0x010x00/0x010x00/0x015F:負號2B:加號ASCII 碼09ASCII 碼09總接觸器0x00:斷開0x01:吸合運行接觸器0x00:斷開0x01:運行平安回路0x00:斷開0x01:正常運行狀態(tài)0x00:檢修0x01:正常表 B.12 續(xù)表 B.115電梯狀態(tài)位Byte8Byte7Byte6Byte5Byte4

18、Byte3Byte20x00/0x010x00/0x010x00/0x010x00/0x010x00/0x010x00/0x010x00/0x01門狀態(tài)轎廂上行轎廂下行平層狀態(tài)上極限下極限報警按鈕0x00:翻開0x00:停止0x00:停止0x00:未平0x00:正常0x00:正常0x00:正常0x01:關(guān)閉0x01:上行0x01:下行0x01:平層0x01:動作0x01:動作0x01:動作表 B.13 續(xù)表 B.126包尾BytelByteOECAD-B.2電梯故障數(shù)據(jù)包37個字節(jié)表B.2電梯故障數(shù)據(jù)包格式表 B.20123包頭狀態(tài)消息代碼終端代碼Byte36Byte35Byte34Byte3

19、3Byte32Byte31Byte30Byte29Byte28EFAE0x03303930393039303930393039-0x02:狀態(tài)0x04:故障ASCII 碼09ASCII 碼09ASCII 碼09ASCII 碼09ASCII 碼09ASCII 碼09表 B.21 續(xù)表 B.204電梯故障位Byte27Byte26Byte25Byte24Byte23Byte22Byte210x00/0x010x00/0x010x00/0x010x00/0x010x00/0x010x00/0x010x00/0x010x00:正常0x01:困人0x00:正常0x01:平安回路斷開0x00:正常0x01

20、:上極限動作0x00:正常0x01:下極限動作0x00:正常0x01:開門走梯0x00:正常0x01:運行超時0x00:正常0x01:反復(fù)開關(guān)門表 B.22 續(xù)表 B.215電梯故障位Byte20Byte19Byte18Byte17Byte160x00/0x010x00/0x010x00/0x01保存保存0x00:正常0x01:長時間開門0x00:正常0x01:非平層停梯0x00:正常0x01:報警按鈕動作保存保存表 B.23 續(xù)表 B.2267時間包尾Byte15Byte2Byte1Byte000:00:0000/00 時:分 :秒日 /年ECAD例如：06:28:13 18/11-附錄C標

21、準性附錄數(shù)據(jù)格式數(shù)據(jù)采集終端與平臺接口協(xié)議C.1協(xié)議概述本標準定義了電梯傳感裝置或 M2M終端與電梯平安運行監(jiān)控網(wǎng)絡(luò)或 MDMS平臺間的接口。 協(xié)議本身以 SMPP V3.4為根底，整體參考SMPP V3.4的報文格式，數(shù)據(jù)類型定義，編解碼方式。MDMS平臺和M2M終端直接的數(shù)據(jù)傳輸需要同時支持SMS、UDP和TCP三種承載方式。無論使用短信、TCP還是UDP傳輸，應(yīng)不影響 MDMS平臺與M2M終端的交互過程。對于 M2M終端和MDMS平 臺的數(shù)據(jù)連接，M2M終端要么一直使用TCP，要么一直使用UDP。如圖C.1所示。MDM平 臺M2M 端Nfc-MDM平臺與終端接口協(xié)議MDM平臺與終端接口協(xié)

22、議SMSTCPUDPUDPTCPSMSw>IPIP底層承載底層承載M2礫端和MDM平臺之間的交互圖C.1協(xié)議使用的端口要求雙方均是可以配置的，對于終端出廠時配置的默認端口：TCP為18585，UDP為18586。終端建立PPP連接后，應(yīng)立即登錄 MDMS平臺。終端從 MDMS平臺退出后，應(yīng)立即斷開 PPP連接。 C.2 通信方式當終端需要和平臺交互時，通過 TCP，UDP的方式登錄發(fā)送請求到平臺，進入正常交互狀態(tài)。如果應(yīng) 用的數(shù)據(jù)傳輸較頻繁，需要終端長時間在線，那么在發(fā)送完數(shù)據(jù)后不退出，通過心跳消息來維持會話；如 果應(yīng)用的數(shù)據(jù)傳輸頻次較低，終端無需和應(yīng)用實時交互，那么終端在發(fā)送完數(shù)據(jù)之后

23、等待較短時間然后直 接退出，下次交互再次登錄。圖C.2為典型的 MDMS 平臺與M2M終端會話交互過程。M2終端MDM平 臺Logi n.J Logi nResp I IHeartBeat»I IHeartBeatResp-II數(shù)據(jù)上傳?IIY 數(shù)據(jù)上傳回應(yīng)- 一II指令下達 IV-指令下達回應(yīng)一IILogout-»Y LogoutResp 圖C.2 MDMS平臺與M2M終端會話交互過程短信也可以被用來作為終端和平臺之間的數(shù)據(jù)交互的承載機制。但短信承載在MDMP協(xié)議中作為TCP/UDP數(shù)據(jù)連接的補充，是一種輔助通信形式，不易過多使用，使用場景應(yīng)局限在特定場合。本標準 內(nèi)容目

24、前不適用于主要依賴短信方式進行通信的終端。C.2.1 通信訪問地址C.2.1.1 TCP 和 UD承載終端使用“域名+端口號訪問MDMS平臺，此地址在M2M終端安裝時將被配置到終端中。終端需 要支持通過短信修改此地址的功能，防止以后平臺升級或者更換域名帶來的額外工作量。對于M2M終端，其IP/PORT是每次連接無線網(wǎng)絡(luò)時動態(tài)獲取的，平臺通過終端發(fā)過來的UDP數(shù)據(jù)包攜帶的IP/PORT地址獲得此時終端的訪問地址如使用TCP，那么直接維護其連接鏈路，平臺對于從終端收到的每個數(shù)據(jù)包上的IP/PORT地址都需要識別，并維護終端和其IP/PORT地址或網(wǎng)絡(luò)連接鏈路的對應(yīng)關(guān)系。其中，對于 UDP承載模式，

25、一次登錄連接過程中，終端的端口號可能會發(fā)生變化。C.2.1.2 SMS 承載終端應(yīng)配置短信接入號。終端應(yīng)只接收來自此短信接入號的短信。C.2.2 心跳處理機制C.2.2.1心跳消息發(fā)送M2M 終端登錄MDMS平臺后，如果長時間不發(fā)送數(shù)據(jù)，須向MDMS平臺發(fā)送心跳消息。通過心跳消息機制，使MDMS平臺及時了解終端登錄后的連接狀態(tài)是否仍然保持。MDMS平臺應(yīng)對心跳消息進行應(yīng)答。C.2.2.2 心跳消息內(nèi)容心跳消息必須包含以下信息：a. 請求類型心跳b. MDMP 協(xié)議版本c. 終端編號d. 終端任務(wù)狀態(tài)： 普通運行狀態(tài)指終端處于普通任務(wù)執(zhí)行狀態(tài)； 分包處理狀態(tài)指終端處于分包狀態(tài)， 執(zhí)行過程中“終端

26、分包事務(wù)標識在終端任務(wù)狀態(tài)為“分包處理狀態(tài)時必須攜帶。注：心跳包不帶 CRC 校驗局部。C.2.3 通信交互方式終端和平臺之間的所有請求，都需要有應(yīng)答。即發(fā)出請求，等待對方應(yīng)答直到超時。應(yīng)答報文 ACK 報文不做應(yīng)答。如果在未發(fā)請求的情況下收到對方的 ACK 報文，那么直接丟棄此 報文。如果收到非本次請求的 ACK 報文，那么直接丟棄此報文。如果收到的報文 CRC 校驗結(jié)果不一致，那么直接丟棄報文。 如果請求方在等待應(yīng)答期間收到對方發(fā)出的非正常應(yīng)答報文和發(fā)出請求不匹配的報文或請求報 文，那么按下述策略處理：如果請求方是平臺，收到終端的非正常應(yīng)答報文，那么丟棄即可。如果收到終端的請求報文，那么放

27、棄 本次請求的繼續(xù)處理，響應(yīng)終端的請求。如果請求方是終端，收到平臺的非正常應(yīng)答報文，那么丟棄即可。 如果收到平臺的請求報文，那么丟棄收到的平臺的報文，繼續(xù)等待平臺對其已發(fā)出的請求的應(yīng)答。C.2.4 應(yīng)答超時處理如果采用UDP方式，M2M終端與MDMS平臺之間的通信不可防止會發(fā)生丟包或超時的情況，TCP方式也可能存在通訊的一方接收失敗的情況。因此，為保證數(shù)據(jù)的可靠傳輸，本協(xié)議采用超時重發(fā)機制。 C.2.4.1 偶發(fā)異常偶發(fā)異常主要指 M2M 終端與 MDMS 平臺之間的通信過程中的偶然的、突發(fā)的、非持續(xù)的丟包情況。圖C.3給出了偶發(fā)異常情況下 M2M終端與MDMS平臺之間數(shù)據(jù)丟包與重發(fā)的交互過程

28、。重復(fù)的包需要和原始包完全一致。皿21終端MDM平 臺Logi nRespI |數(shù)據(jù)包n請求喪失f數(shù)據(jù)包n請求I重發(fā)I* 數(shù)據(jù)包n應(yīng)答一一數(shù)據(jù)包m請求喪失'| 一 數(shù)據(jù)包m青求I重發(fā)I- 數(shù)據(jù)包m應(yīng)答 一a圖C.3偶發(fā)異常情況下 M2M終端與MDM平臺之間數(shù)據(jù)交互過程C.2.4.2通信故障當丟包連續(xù)出現(xiàn)到一定程度時，那么M2M終端與MDMS平臺之間處于通信故障狀態(tài)。如果MDMS平臺檢測出通信故障，那么向相應(yīng)的終端發(fā)送遠程控制指令RemoteControl強制終端退出連接，然后斷開鏈路，并將終端狀態(tài)標記為未登錄。如果是終端檢測出通信故障，那么向平臺發(fā)送Logout報文，然后斷開PPP連接

29、，根據(jù)自身需要休眠一段時間后，再決定是否再重新登錄平臺。重復(fù)消息處理終端和平臺交互的報文都有消息序號，通過消息序號Seque nce_No來唯一標識一個消息報文。消息序號的第一個作用是匹配請求報文和應(yīng)答報文。即應(yīng)答報文的序號必須與請求報文的序號字段 一致。消息序號的第二個作用是區(qū)分新舊報文。請求報文發(fā)起方分配消息序號，取值范圍為0x0000 -OxFFFF。順序累加，步長為1，循環(huán)使用。終端登錄之后，終端和平臺需記錄兩個Seque nce_No：1.自身發(fā)出的請求序列中最近一次所用的Sequence_No 記為A 。除非特別指明的情形，自身發(fā)出下一請求報文時，Seque nce_No應(yīng)為A加1

30、2收到對端發(fā)出的請求序列中最近一次所用的Sequence_No 記為B。正常情況下，收到對端的下一個請求報文的Sequence_No應(yīng)為B加1為防止在接收到對方的重復(fù)請求消息時通過消息序號來判定，執(zhí)行不必要的操作，終端和平臺都應(yīng)對最近處理的請求消息的應(yīng)答報文和對應(yīng)的消息序號進行緩存。當收到對方請求消息后，首先按照消息序號檢查緩存的應(yīng)答消息隊列，看是否對該消息序列已回復(fù)過應(yīng)答。如果相同消息序號的應(yīng)答消息 存在，那么可認為對方重復(fù)發(fā)送了消息，對該重復(fù)消息應(yīng)不做處理，只將消息序號匹配的應(yīng)答消息取出， 并重新發(fā)送給對方；如果相同序號的應(yīng)答消息不存在，且此序號大于目前接收到對方的消息序號，那么平 臺應(yīng)正

31、常響應(yīng)。否那么，直接丟棄報 文。如果是平臺發(fā)現(xiàn)發(fā)生了這種情況，需要記錄日志，而且假設(shè)此現(xiàn)象 如果發(fā)送頻率較高，平臺應(yīng)生成告警。MDMS 平臺緩存回復(fù)的應(yīng)答消息以及對應(yīng)的消息序號時，采用條數(shù)和時長綜合考慮策略。終端應(yīng)緩 存接收到平臺下發(fā)的最后 X 條請求消息的消息序號以及對該消息的應(yīng)答報文。 X 缺省為 3。如果收到重復(fù)的 ACK 消息，那么直接丟棄此消息。C.2.6 分包交互處理如果采用UDP傳輸方式，每包大小限制為 1Kbyte 指整個報文的長度。如果數(shù)據(jù)超過以上限制， 那么必須進行分包處理。支持分包的報文類型有：1 REQ_CONFIG/REQ_CONFIG_RSP 報文2 SET_CON

32、FIG/SET_CONFIG_RSP 報文3 GET_CONFIG/GET_CONFIG_RSP 報文4 SUBMIT_EVENT 報文其它報文不支持分包。其中，“ SUBMIT_EVENT 報文指以下報文類型：1 遠程參數(shù)配置結(jié)果通知對應(yīng) SET_CONFIG 消息2 終端觸發(fā)事件通知目前對應(yīng)終端狀態(tài)監(jiān)視任務(wù)3 終端請求配置參數(shù)配置失敗通知不過，終端觸發(fā)事件通知目前對應(yīng)終端狀態(tài)監(jiān)視任務(wù)不建議 進行分包。假設(shè)狀態(tài)參數(shù)很多，確實需要分包，可采用設(shè)立多個狀態(tài)監(jiān)視任務(wù)的方法完成。 平臺按終端型號維護終端能夠分包的最大數(shù)量，如果平臺下發(fā)的請求報文分包數(shù)量超過了此數(shù)量， 平臺應(yīng)放棄下發(fā)，并發(fā)出告警。建議分包數(shù)量限制在5個以下。終端支持發(fā)出大小至少為 1K的單個UDP分包。單個分包過程不能 跨兩次登錄。連接中止，意味著分包狀態(tài)終止平臺要有分包記錄日志，包含每個分包，以及整個報 文的信息。分包交互機制的根本原那么：1本協(xié)議采用專門的分包傳輸命令字來發(fā)送報文子包；2為最大限度利用每個子報文的承載能力，減少子報文的總數(shù)目，一個TLV 可以被拆分到序號相鄰的子報文中；3每個子報文的報文序號按本協(xié)議對報文序號的規(guī)定遞增處理；4在發(fā)生異常的情況下，應(yīng)答方和請求方都可以中止分包交互狀態(tài)；5子包全部完整接收完成后，再執(zhí)行報文所承載的命令；6分包機制遵從本標準對于報文的所有規(guī)定；7分包中止，