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

搞動環監控的是騙子，身為業內人士，內心沉重。 

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

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

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

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

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

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