今天被教育了,以前我程式設計的時候,確實很少考慮可靠性的問題,今天問了同事兩個問題,得出兩條:
1、凡是外部輸入都是不可靠的。
有乙個模組裡,fpga會週期性的產生中斷請求給arm,但程式中用了arm內部定時器來監視這個fpga中斷,若長時間沒有中斷,將顯示錯誤,並關閉輸出。我剛看時就這覺得這樣的**多餘,經解釋之後發現至少有兩點必要:
1)在最終的產品中,fpga可能壞了,不能正常工作了,但是系統必須保證輸出在此時被關閉,避免重大事故發生的可能。
2)在生產過程中,fpga可能出現,未燒邏輯或燒寫了錯誤的邏輯或虛焊了,必須能夠快速地定位出是fpga的問題,以便及時地修正。
2、輸出不變時,仍然要週期性的輸出。
為什麼外部輸出未改變值時,仍要執行輸出操作呢。我們這個輸出還是在中斷中完成,我乍一看,感覺如果輸出不變,乾脆就不要輸出了,節約cpu時間。但是其實不然,為了增加可靠性,即時輸出未改變,仍然要週期性的執行輸出操作。因為:
在工況中,外部的暫存器(273)很可能被干擾,發生誤動作,此時若能及時停止這個誤動作,很可能就避免了一些悲劇的發生。若認為輸出無變化,就不執行輸出操作,誤動作就沒有機會修正。
作為工控行業,關於可靠性設計真的要多想想,今天北京4號線發生電梯倒退致人死亡的事故,值得我們吸取教訓。感覺教育我的同事!!
App可靠性設計
可靠性是軟體乙個重要的質量屬性,它關注的是軟體功能持續的可用性,以及出現故障之後是否能夠容錯,是否能快速的恢復使用。1 故障應在第一時間被檢測和感知 2 能避免的故障都不應該發生 3 不可避免或無法 的故障,需進行容錯 4 已發生故障,需在最短時間內得到恢復 5 物件狀態和生命期都應該是完備的,閉合...
App可靠性設計
可靠性是軟體乙個重要的質量屬性,它關注的是軟體功能持續的可用性,以及出現故障之後是否能夠容錯,是否能快速的恢復使用。1 故障應在第一時間被檢測和感知 2 能避免的故障都不應該發生 3 不可避免或無法 的故障,需進行容錯 4 已發生故障,需在最短時間內得到恢復 5 物件狀態和生命期都應該是完備的,閉合...
12 1 19進步一小點
1,關於html的一些基礎知識 在表單中,action的值代表伺服器的哪個程式接受你的資訊,而method則是客戶端是通過什麼方式提交的,一般有get,post get則是一般當我們提交的時候,所寫的內容會跟在url後面,有兩個缺點 一是不安全,二是有長度限制 post則相對克服了上面的兩個缺點 2...