故障樹手冊(Fault Tree handbook)(1)


本文原書爲Fault Tree Handbook,所有者爲美國核管理委員會(NUREG-0492)。當時學習的時候感覺這本書很不錯,故障樹對於系統分析很有用,而國內的參考資料相對比較少,就把這本書翻譯了下來。本文的英文版所有權歸原書發行單位所有,中文翻譯的所有權歸作者趙星漢所有,未經作者許可,任何人不得將本文用於盈利。

前言

1975年以來,一個題爲“系統安全和可靠性分析”的短期課程向200多名核管制委員會人員和承包商開展。本課程由系統科學研究所的David F. Haasl教授、華盛頓大學的Norman H. Roberts教授和美國核管理委員會概率分析人員負責講授,是概率分析職員組織(Probabilistic Analysis Staff)資助的風險評估培訓計劃的一部分。
本手冊不僅可以作爲系統安全可靠性課程的教材,而且還是一份關於故障樹構建和評估的文檔。這本書的出版是按照風險評估審查小組報告(NUREG/CR-0400)的建議,其中指出,故障/事件樹方法應在覈管理委員會內外得到更廣泛地使用。希望該文件有助於系統分析中故障樹方法的制度化和系統化。

(趙星漢同學:在本書中,使用了Fault和Failure兩個概念,爲了便於區分,在翻譯中,我們將Fault翻譯爲“故障”,將Failure翻譯爲“失效”。)

第一章 系統分析的基礎概念

1.1 系統分析的目的

這本書的主要關注是故障樹的相關技術,這是一種獲取系統信息的系統化方法。按照該方法獲取的信息可以用於決策。因此,在定義系統分析之前,我們應該對決策的過程做一個簡要的檢查。決策是一個非常複雜的過程,我們將重點介紹有助於系統分析的方面。

大體上來說,我們所做的任何決策都基於我們對目前情況的瞭解。這種知識部分來自我們對相關情況的直接經驗,或來自類似情況的相關經驗。通過適當的實驗和對結果的分析,我們的知識能得到一定的提升。從某種程度上來講,我們的知識基於推測,而推測則與我們對事務的看法是樂觀的還是悲觀的有很大的關係。例如,我們可能會相信,“在這個最好的世界裏,一切都是爲了最好的”;或者,反過來,我們可能相信墨菲定律:“如果任何事情都能變糟,那它就會變糟。”因此,知識可以通過幾種方式獲得,但在絕大多數情況下,不可能獲得所有相關的信息,因此也幾乎不可能消除所有的不確定性因素。

當所有相關信息都收集起來之後再做出決定,這本身就是一個沒有意義的假設,這與我們日常生活中被迫做出決定的時機相差甚遠,我們一般不可能有十分完備的信息,我們都要面臨最後的期限要求。此外,由於在必須作出決定時通常不可能獲得所有相關的數據,所以我們根本很難完全弄清楚該決策所導致的全部後續影響。模型I-1 給出了該思想的原理。

在這裏插入圖片描述

由於決策過程往往伴隨着時間的限制,因此我們需要區分“好的決策(good decision)”與“正確的決策(correct decision)”。當我們對一件事情進行總結時,我們能判斷決策是“好的決策(good decision)”或者“壞的決策(bad decision)”。例如,我買了1000股XYZ公司的股票。六個月後,我發現股票漲了20點,則我之前的決策就是“好的決策(good decision)”。但是,如果股票在這段時間下跌了20點,那麼之前的決策就是個“壞的決策(bad decision)”。儘管如此,如果在我做決策時,當時所有可用的信息都表明XYZ公司有一個美好的未來,那麼即使後續股票下跌,當初買入股票的的決定依然是一個“正確的決策(correct decision)”。

做出正確的決策(correct decision),需要以下幾個方面:

  1. 識別所有與決策有關的信息。
  2. 建立能獲取相關信息的系統流程。
  3. 對按流程所獲得的信息進行合理的評估和分析。

人們對系統分析有很多種定義。本書的作者們進行過長時間的思考和討論,選擇瞭如下的定義:

系統分析是指爲了制定決策,對特定系統信息進行有序、及時的收集和調查的過程。
(System analysis is a directed process for the orderly and timely aquisition and investigation of specific system information pertinent to a given decision.)

根據上邊的定義,系統分析的主要功能是對信息的收集,而不是生成系統模型。這本書的重點(至少在開始階段)將放在過程(信息的獲取)上,而不是產品(系統模型的生成)上。該重點的劃分是十分必要的,因爲缺乏科學有序的信息收集過程,對應的系統模型往往並不準確和完備。

在信息收集開始前,我們必須確定哪些信息是與決策有關係的。什麼信息是必須(essential)的?什麼信息是需要(desirable)的?這一點看起來十分簡單和自然,但是令人驚訝的是,很多情況下人們並沒有遵循這條基本原理。圖I-2描述了可能發生的情況。

在這裏插入圖片描述

我們假設圖中的大圓表示做出正確的決策所必須的信息。現實中的情況往往是:喬恩斯教授是一個該領域中的一個子領域A的資深專家,並且資金充足。當他開始他的調研後,他的調研發現了一些未知的有意思的問題,這些問題位於A子領域的A1分支上。對A1的調研又導致了A2,如此往復。注意,喬恩斯教授的調研工作使他得到的信息距離實際的決策需要越來越遠。阿爾法實驗室在一個子領域B的科研中具有重要的位置,調研工作往往從B1導致B2,同樣的事情一直在不斷髮生。當需要決策的時候,必要的決策支持信息並不完備,然而如果有適當的引導,他們的工作本應該是可以獲得充足的決策所需的信息的。

一個自然的決策過程如同圖I-3所示,A模塊表示一個確定的實體。初始階段,一個實體就像一本“閉合的書”,但是通過實驗和調查,我們將會建立對該實體的感知。這時我們會得到代表這個實體的模型B。下一步,通過分析該模型,我們能得到一些結論,這些結論將作爲我們決策的基礎。因此,我們的決策實際上是我們所建立的模型的衍生物,如果模型建立的不正確,則決策也將是錯誤的。很明顯,決策過程的核心應該是保證所建立的模型應儘可能的與實體相一致。

在這裏插入圖片描述

1.2 系統的定義

在前文中,我們定義了“系統分析”,但什麼是“系統”呢?我們常常會說到“太陽能系統”,“政府系統”,“通信系統”等,在這種語境下,系統指的是多個不同種類元素通過某種組織形式存在於一起,它們以某種方式相互作用,這種方式可能是定義好的,也可能是沒有完善的定義的。於是,我們可以對系統做出如下的定義:

系統是由相互作用的離散元素集合所構成的確定性實體。(A system is a deterministric entity comprising an interacting collection of discrete elements.)

從實踐的角度來看,這個定義並不是很有用,在一些特定的情況下,我們必須指定系統執行的哪些方面是需要着重關注的。系統執行某功能,而對特定執行的狀態的選擇將決定進行何種分析。例如:我們是否對系統是否成功完成某些任務感興趣;我們感興趣的是系統是否會以某種危險的方式失效;或者我們感興趣的是,該系統是否會比最初預期的成本更高?在這三種情況下,正確的系統分析很可能基於不同的系統定義。

“確定性”一詞在定義中意味着所討論的系統是可定義的,試圖對無法明確定義的事物進行分析是完全徒勞的。詩人但丁將地獄看作一個系統,並將它分成了很多令人痛苦的層次,但是,從實踐的角度來看,這種系統是很難像家裏的管道系統那樣被準確的定義。此外,一個系統應該有一些目標——它必須實現某種功能。例如運輸系統,熱水管道循環系統,地方學校系統等,它們都有自己明確的目標,而不是簡單的存在於虛構中。

定義中的離散元素同樣也必須是可定義的。例如,太平洋潛艇艦隊中的獨立潛艇就是其中的可定義元素。需要注意的是,離散元素本身也可以被看成系統。比如說,潛艇由推進系統,導航系統,船體系統,管道系統等組成,它們又可以再向下進一步的劃分。

從系統定義中可以看出,系統是由相互作用的若干部件和子系統組成。這些元素間的相互作用可能會非常複雜,這就決定了一個系統的複雜程度不僅僅是這些部件元素相疊加這麼簡單,這是本書將不斷強調的重點。此外,如果系統任何部件的物理特性發生變化(例如,是故障導致的),系統本身也會產生變化。這是一個重要的觀點,在某些設計中,假設引入的故障會導致系統的原先的設計發生變化,那麼則應針對變化後的新系統開展進一步的分析。以一架四翼飛機爲例。假設一個引擎失靈。我們現在有了一個與原來大不相同的新系統,新系統的着陸特性與原系統相比發生了巨大的變化。假設有兩個引擎失靈,則會出現六個不同的可能的系統,這取決於哪兩個引擎出了故障。

也許在系統定義中必須做出的最重要的決定是如何在系統上設置外部邊界。想象一下放在桌子上的電話,簡單地將系統定義爲儀器本身(耳機、線和支架)就足夠了嗎?還是應該包括連接牆上插孔的線路?電線杆的外線呢?電線杆上的接線盒呢?那麼,由本地、全國乃至全世界的電話系統所組成的龐大而複雜的線路、交換設備等又該怎麼辦呢?很顯然,必須建立系統的外部邊界,並且應該根據系統性能的所關注的方面進行決策。如果當前的面臨的問題是電話聲音太小,那麼分析所建立的系統外部系統邊界將比較小。如果該問題涉及到線路上的射頻傳輸,則外邊界範圍將變得很大。

系統定義中的另一個重心是建立分辨極限(limit of resolution)。在電話的例子中,是否應該延申我的分析範圍到每個組成設備的獨立的部件(螺絲,信號發射器等)?或者是否必要進一步延申到分子層面,或者原子層面或者更低的層面?總而言之,系統分析應該細化到何種程度,與我們需要決策的內容相關。

我們目前所討論的內容可以用圖I-4表示,圖中的外部的虛線將系統與它所處的環境分隔開來,這條虛線構成了一條系統的外部邊界。我們將系統劃分成A,B,C等幾個子系統,這樣做的目的將在適當的時候討論。還要注意,爲了便於分析,其中一個子系統F已經被分解爲更小的“子—子系統”。這就構成了對系統內部邊界的選擇。F中各個子子系統,以及a、b、c等子系統,就是系統的定義中所指的“離散元素”。

在這裏插入圖片描述

在某些特定的情況下選擇適當的系統邊界是一件至關重要的事情,因爲外部邊界的選擇決定了分析的全面性,而分辨極限的選擇則限制了分析的細節。該問題的幾個方面將在這裏簡要的說明,並將在整本書中進行強調,特別是在各類應用。

到目前爲止,我們討論的系統邊界都是物理邊界。在許多情況下,在系統上設置時間或類時間的邊界也是可能且必要的。比如說一個男人,他習慣每兩年換一輛新車。在本例中,系統是車,我們感興趣的方面是車的保養策略。很明顯,在兩年時限的時間的邊界內,他的維護策略就是有一件事,它將與一個習慣於將車開到報廢的男人所採取的策略有很大的區別。在某些應用中,系統的物理邊界實際上可能是時間的函數。這方面的一個例子是,系統的時間邊界表示不同的操作階段或不同的設計修改,在每一階段的變化或設計修改後,物理邊界將被重新審查並可能發生變化。

系統分析人員還必須問這樣一個問題:“所選擇的系統邊界是否可行?從分析的目標來看,它們是否有效?”要對一個系統得出某些結論,可能需要在外部邊界中包含一個大的系統“容量”。這可能需要廣泛而耗時的分析。如果沒有足夠的資金、時間和工作人員來完成這項工作,也就不可能有更有效的分析方法,那麼就必須把外部邊界向內收,減少預期從分析中得到的信息量。好比我擔心我的電視接收情況,我可能希望在我的分析中包括電離層的狀態,但這肯定是不可行的,行之有效的辦法應該是嘗試電視天線最佳的接收姿態。

分辨極限(內部邊界)也可以從可行性和分析的目標來確定。建立一個針對電視機總體可靠性的有價值的研究,而不去關心微觀和亞微觀層面上發生的事情,是具備相當的可能性的。如果要計算系統總體故障概率,則分辨極限影包括可獲取的各類組件故障。不管怎樣,一旦選擇了分辨極限,就定義了“離散元素”,我們所關心的也就成了這個層面上的相互作用,更低層面上的交互將被忽略。

我們現在可以看出來,系統的外部邊界用於描述系統的外部輸出(系統對環境的影響)和輸入(環境對系統的影響);分辨極限則用來定義系統的“離散元素”,以建立系統內部的基本交互作用。

具有相關技術背景的讀者或許會發現我們的系統及其邊界的定義類似於一個經典熱力學過程,其中有一個實際的物理邊界或一個虛構的邊界,該邊界用於隔離一定質量的物質(質量控制)或者一定體積的物質(體積控制),系統的輸入和輸出由進出有界區域的能量或質量來確定。我們把不與環境交換質量的系統叫做“封閉系統”,而在封閉系統中,不予環境交換能量的系統稱爲“絕熱系統”或者“孤立系統”。一個曾研究過熱力學問題,尤其是流體問題的學生,會對在嘗試解決問題之前建立適當的系統邊界的重要性留下深刻的印象。

充分的思考來正確分配系統的邊界和分辨極限是十分必要的。一種最合適的說法是,系統的外部邊界和分辨極限應該在系統分析前進行定義,並在分析的執行過程中同步修正。在實際情況下,由於在分析過程中信息的不斷獲取,系統的邊界和分辨極限常常需要修改。例如,可能會發現系統結構圖不像最初設想的那樣詳細。在任何分析中,系統邊界和決議的限制,以及任何修改,都必須明確定義,並且應該體現在發佈的報告中。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-DLCYNknN-1586400226597)(asserts/FigureI-5.png)]

爲了闡述內邊界和外邊界的其他方面,我們繪製了圖I-5。內部的實線繪製的圓表在這裏插入圖片描述示我們的系統邊界,我們考察該邊界以內的事件發生概率,我們假設發生概率爲10310^{-3}階或更高。如果系統邊界擴大到圖中的虛線位置,事件發生的概率爲10410^{-4}階或更高。假設需要給圖中實線部分的系統設計一個雙重冗餘,我們需要將事件發生的概率限制在103×103=10610^{-3}\times 10^{-3}=10^{-6}階,但是,假設邊界設計的不正確(例如本來應該考慮虛線邊界卻只考慮實線邊界內),我們忽視的事件發生的概率就會產生致命後果,我們就會產生錯覺,認爲我們的系統比實際情況要安全或可靠兩個數量級。缺乏細緻思考的可靠性計算往往會產生這樣荒謬的數字,如101610^{-16}101810^{-18}。較低的數字只是表明,系統不會以預先考慮的方式失敗,而是以一種未被考慮的方式,以高得多的概率失敗。

趙星漢同學:原文章裏寫的很難懂,這一段其實是說如果外邊界劃分的不正確,可能會把一些需要考慮的故障事件排除在設計之外,以至於在完成可靠性設計後,在我們考慮到的失效模式上是滿足設計指標的,但系統卻可能會以我們沒有考慮的模式發生失效

1.3 分析方法

本書中,我們所關注的是某些正式的過程和模型。這些模型應該可以按照人類常規思維那樣進行分類。人類常用的思維方式有歸納法和演繹法兩種。這裏有必要對兩種方式各自的特點進行討論。

1.3.1 歸納法(Inductive Approaches)

歸納法是從單獨的個案中推導出通用性結論的方法。以一個特定的系統爲例,我們假設在啓動條件上有一個特定的故障,並試圖確定該故障或條件對系統運行的影響,我們就構建了一個歸納的系統分析。因此,我們可以探討某些特定的控制面損失如何影響飛機的飛行,或探討預算中某些項目的取消如何影響學區的整體運作。我們也可以詢問不插入給定的控制棒如何影響緊急停堆系統的性能,或者給定的初始事件(如管道破裂)如何影響工廠安全。

歸納系統分析的方法很多,我們將在第二章專門討論其中最重要的方法。該方法的實例有:初步危害分析(PHA)、失效模式與後果分析(FMEA)、失效模式效應與臨界性分析(FMECA)、故障危害分析(FHA)和事件樹分析。

再次強調——在歸納方法中,我們假設一些可能的組成條件或初始事件,並試圖確定其對整個系統的相應影響。

1.3.2 演繹法(Deductive Approaches)

演繹法是從一般原理推導至具體事件的方法。在演繹法中,我們假設一個系統以某種形式失效,我們試圖找出是系統或者組件的什麼行爲模式導致了導致了這次失敗。按照通俗的講法,我們把這種方法叫做“夏洛克福爾摩斯”原理。福爾摩斯面對證據,需要重新再現引發犯罪的各類事件。事實上,所有成功的偵探都是演繹法的專家。

生活中常見的演繹法使用場景是事故調查。是什麼事件鏈導致了“不沉之船”泰坦尼克號在首航的沉沒?是儀器故障還是人爲故障導致了一架商業客機墜毀在山腰上?

這本書的主題——故障樹分析,也是演繹系統分析的一個例子。在這種技術中,假定了某些特定的系統狀態(通常是故障狀態),並以系統的方式建立了導致這種不希望發生的事件的更基本的故障鏈。故障樹分析的基本原理,以及與故障樹的應用和評估相關的細節將在後面的章節中給出。

總之,使用歸納方法來確定哪些系統狀態(通常是失敗狀態)是可能的;演繹方法用於確定給予者系統狀態(通常是失敗狀態)是如何發生的。

1.4 風險與陷阱

在對系統的研究中,有一些危險的暗礁,這些暗礁限定了分析員必須航行的航線。大多數問題集中在界面的角色:子系統接口與規程接口。

1.4.1 子系統接口

大體說來,系統是一個子系統的綜合體,這些子系統由一些不同的分包商和組織進行製造。每個分包商或組織都採取適當的步驟來確保其產品的質量。問題是,當把子系統放在一起形成整個系統時,從單獨的組成部分來看,失效模式可能根本不明顯。重要的是,在要集成的分析中使用相同的故障定義,另一個非常重要的方面是,系統邊界和分辨極限必須清楚說明,以便識別任何潛在的隱藏故障或不一致之處。如果要對集成系統進行評估或量化,則應使用相同的事件標識符,以避免出現歧義。接口問題通常存在於控制系統中,最好不要將任何控制系統分割成“塊”。具有控制系統接口的系統(例如,噴淋系統具有噴淋信號輸入)可以用適當的“位置”進行分析,以便作爲一個整體進行控制分析。這些“位置”或轉移將在稍後的故障樹分析討論中進行描述。

1.4.2 規程接口

由於不同學科或不同工作領域的人持有不同的觀點,所以經常會出現困難。這位電路設計師認爲他設計的電路是完美的,是藝術與科學的結合,應該受到溫和的操作和科學的維護。另一方面,用戶可能不會這樣。他把它扔在地上,踢它,粗暴的對待它。

一位作者年輕時曾被僱用爲海洋製圖員。原車間項目正在制訂掃雷計劃。繪圖員被分成幾組。有船體部分、線路部分、管道部分等等,每個部分都在自己的技術領域內愉快地工作。但是當一個製圖員試圖制定一個複合的隔間(陀螺的房間,在這種情況下),發現船體特性和管道設備是經常不相容,與通風管道線路和管道經常矛盾,事實上,船員不能正常打開房間門,因爲下水道的位置在上層甲板。這個實踐證明了對系統集成的明確需求。

其他的衝突很容易想到:工程主管期望從他的數學部分得到定量的結果,但卻只得到了完善的存在證明;安全協調員在系統中安裝了太多的安全設備,以至於可靠性人員根本無法讓系統正常工作等等。

以操作人員和維護人員之間的接口爲例,考慮每月進行5分鐘的在線維護檢查而停機的系統,假設由硬件故障導致的系統故障概率爲每月10610^{-6}。然後,按月計算,系統不可用的總概率是由於硬件故障而不可用和由於維護策略或
106+1/12720106+104 10^{-6}+\frac{1/12}{720} \approx 10^{-6}+10^{-4}
其中

  • 106=10^{-6} = 系統每個月因爲硬件故障導致的失效
  • 720  =720 \ \ = 一個月的小時數
  • 1/12=1/12 = 每個月維護檢查的小時數

請注意,由於我們的維護策略(每個月只有5分鐘停機時間)導致的系統可用性的概率比由於硬件故障導致系統宕機的概率大兩個數量級。在這種情況下,最好的維護政策就是根本不維護。系統分析者(系統集成者)必須有足夠的知識積累,以便在已出現和將要出現接口問題時能夠識別它們。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章