最近在查一些關于動環(huán)監(jiān)控方面的資料，很多人都在抱怨誤報警呀、誤操作呀。有些人直接說我們

搞動環(huán)監(jiān)控的是騙子，身為業(yè)內人士，內心沉重。 

      很多人認為監(jiān)控軟件里面出現(xiàn)的誤報警呀，誤操作呀是軟件做的垃圾。其實很大成分是冤枉了軟件，其實稍懂點軟件的人都知道，監(jiān)控軟件是相對對較簡單的軟件，光要做穩(wěn)定，其實是不難的（做的漂亮、功能強大是另外一個話題）。很多情況是位于底層的硬件平臺不穩(wěn)定、串口透傳誤碼率高引起的,才導致軟件眾多問題的。

      在分析這個問題之前，我引入一個概念“透傳設備固有誤碼率”。我的定義是這樣的，在實驗室情況下，把所有設備集成起來，SDH傳輸云用一根1米長的同軸線代替。然后服務器向虛擬串口或者Socket的端口發(fā)送數(shù)據(jù)，這些數(shù)據(jù)通過全部設備后，最終能從物理串口里面采集到，然后在物理串口里接入一個自環(huán)頭，串口數(shù)據(jù)再次通過透傳設備，最終返回到服務器的虛擬串口或者Socket，然后比較兩者的差值。

    現(xiàn)在很多抽時隙方案或者2M環(huán)方案，這個串口誤碼率的指標非常不好，有的誤碼率達千分之幾， 有的甚至高達百分之幾。這方面，我們的設備串口誤碼率這項指標做的很好，壓力測試下，可達20萬分之1.

    再說傳輸鏈路誤碼率，我查了下資料，基站的2M誤碼率要求低于是100萬分之1.一旦誤碼率高于這個指標，很多基站里面的主設備會亮黃燈報警。但是也不排除部分2M鏈路時不時的會來一下高誤碼率，比如高于千分之一.傳統(tǒng)的抽時隙方案，因為傳輸鏈路只有一條，一旦鏈路誤碼率高，會把這個誤碼率疊加到串口誤碼率上面。雙向自愈2M環(huán)，因為有1+1保護，一旦一條鏈條誤碼率高，會自動切換到另外一條鏈路上面去。兩條鏈路同時出現(xiàn)高誤碼率的概況遠遠要小于一條鏈路。

     終端設備應用層分析，一般串口應用層協(xié)議包括包頭+地址+內容+校驗+包尾。我們用簡單的開關量環(huán)境監(jiān)控儀做舉例， 開關量環(huán)境監(jiān)控儀是定時主動上送信息包，經(jīng)過SDH傳輸云和傳輸設備，到達服務器的虛擬串口或是Socket端口。但是如果透傳的串口通道誤碼率高，這個包出現(xiàn)個部分數(shù)據(jù)錯誤。服務器在解析這包的時候，還要自己運算一邊校驗。如果自己的校驗和數(shù)據(jù)包自己帶的校驗一致，那么解析該包數(shù)據(jù)，就是在監(jiān)控軟件里面看到是（溫度超限、濕度超限、煙霧、門磁、水浸、交流掉電）等狀態(tài)。如果校驗不一致，不解析該包。但是校驗里面存在碰撞率這個概念，即不同的數(shù)據(jù)，其校驗值也可能是一致的。這時候就把內容錯誤的一包數(shù)據(jù)也解析顯示在監(jiān)控軟件里面，這就是我們常碰到的監(jiān)控軟件誤報警現(xiàn)象。當然不同的校驗算法有不同的碰撞率，crc16碰撞率要比普通的奇偶校驗要小的多。

     總結一下：要消除監(jiān)控誤報警需要在三個方面同時下功夫：首先透傳設備本身的誤碼率要小。其次盡量選擇高質量的傳輸鏈路，有條件的話，上雙環(huán)冗余保護。最后是在挑選環(huán)境監(jiān)控儀等設備時候，要求串口協(xié)議校驗起碼是Crc16或者是Crc32.不推薦使用簡單奇偶校驗的設備。