|
作者：模擬示波器 我們給企業做的樣機出現了一種隨機故障：多數情況下，儀器工作正常，先進行不定長度的噪音檢測，然后開始正式采集，噪音很小，采集信號也正確。但是，偶然的，噪音檢測信號突然變得很大。關機再開機，一切又正常了。 讓故障重復發作，需要足夠的耐心。找到重復發作的規律，又需要足夠縝密的思維。反正，誰遇到這種隨機故障，都是頭大。 我們先對異常的信號進行了分析，很快就找到了異常的表象原因：我們的每個樣點數據都是32位的，其中高8位（簡稱A）是通道號標記，有規律，低24位（簡稱B/C/D)是實際數據。通過簡單的分析就能發現，異常的原因是高16位和低16位顛倒了。如果原始噪音數值密布在低8位D上，那么新的數據格式是C/D/A/B，顯然，數據就變得龐大且混亂。 但是，是誰讓高16位和低16位發生了顛倒，卻讓我們傷透了腦筋。 學生們做了很多實驗，試圖找到故障出現的規律，但是結果比較混亂，越到后面，就越混亂，像索馬里的內亂，無可收拾了。今天我讓他們把整個結構講了一遍，用概率分析方法，基本找到了故障源。 先陳述一下我們的設計：上位機是PC機，中間級是DSP，底層是FPGA和ADC。上位機發出兩種工作模式，第一是噪音檢測，就是在**爆炸前，先檢測背景噪音，如果太大，就不引爆**，如果合適，就進入正常采集模式，也就是第二種工作模式。注意，第二種工作模式，全套流程都是確定性的，但第一種模式，隱含著隨機性，測試員觀察背景噪音，覺得噪音不大，他隨時都可以終止目前的噪音檢測，而進入正常采集。 這個終止的時刻，就是隨機的根源。 ADC每125us吐出一次數據交給FPGA，是32位的。FPGA把他們擺放成高16位，低16位兩個寄存器中，同時DSP實施一次讀操作，FPGA自動將高低計數器HL實施0、1轉換。注意，DSP成功讀取全部數據，需要10us~23us，一旦讀完，高低計數器自然歸零。因此，如果在DSP不讀取數據的時刻，終止程序進入第二模式，就不會發生任何問題。在DSP讀取了偶數次，HL也歸零，也不會出問題。問題在于，如果DSP剛好讀取了奇數次，接到了高級中斷，迫使其退出讀取，準備實施第二模式（正常采集）時，HL仍處在1狀態。 此時，DSP向FPGA發出了復位信號，按說可以對HL進行清零，但是問題就出現在這里。我們的學生設計的流程中，DSP雖然接到高級中斷，請求進入第二模式，也向FPGA發出了復位命令。但是，FPGA沒有清零HL計數器。 這樣，啟動正常采集后，DSP讀取的第一個數據，不是應該的高16位，而是低16位，數據就亂套了。 我們隨后分析了出現概率，125us一次中，如果高級中斷發作于10us~23us之外，不會出問題。發作于10us~23us之內，也只有剛好讀取了奇數個數據時，才會出問題。因此故障概率為(5~11.5us)/125us，大約是1/25~1/10.8。 事實證明，我們的實驗，有時第一次就出錯，有時七八次，但是絕大多數情況下，30次之內必然出錯。這與我們的分析完全吻合。 我猜測，在錯誤的情況下，繼續實施噪音檢測，肯定會在相同的概率下，由錯誤再回歸到正確。我提出了若干估計，要求學生大量實驗去驗證： 1）任何錯誤的出現，此前一次的模式一定是噪音檢測。噪音檢測的終止時刻不合適，是造成出錯的本質原因。 2）出錯概率大約為1/20附近。 3）出錯后繼續實施噪音檢測，將會出現正確回歸。 學生大量實驗告訴我，與我估計完全相同。 解決問題的方法其實很簡單，就是FPGA對DPS發出的復位信號，實施一個有效的動作：將HL計數器清零即可。 事實證明，這么修改后，再也沒有出現過任何故障。 從這個故障排查的歷程，我想告訴大家。 第一，隨機故障一般都有隨機性事件引起，找尋隨機性事件，有助于發現故障根源。 第二，隨機故障一般都有隨機性概率，這個概率一般可以從時序上分析得來。 第三，只有分析概率與事實概率吻合，才說明找到了故障源。 第四，只有找到了故障源，且證明兩者概率相同，才能一針見血排除故障。 上面文字在人人中發表。補充一句，為什么要搞概率分析。隨機故障讓人頭疼的地方，就是你解決了，心里還是不踏實。除非持續的，大量的，無休止的實驗，能讓你放心一些。這誰都受不了。但是，如果找到了概率，且實驗與概率相同，一般情況下，我們就能徹底放心了。 |
