摘要：
　　
　　從實現過程功能安全要求的基本規范IEC61511所給出過程工業中工廠安全保護防災結構體系（見圖l），可以清晰地看出安全儀表控制系統SIS是過程工業預防災害和減災的兩個重要環節，確保安全儀表系統的功能安全則是預防和減災的一種基礎保證。本文希望從功能安全的基本概念出發討論怎么才能切實實現控制系統的概念安全。
　　
　　一、控制系統功能安全的標準
　　
　　IEC61508/GB20438《電子/電氣/可編程電子安全相關系統的功能安全》是一個宏標準，規范了滿足安全相關系統功能安全的基本要求和規則。通過應用嚴格的系統性的過程，以可追溯性、關鍵性分析、驗證（verifiCation）和確認（validation）的程序為重點，來評估是否滿足功能安全的標準要求。IEC61508標準的一個重要突破就是制訂了一整套完整的開發程序和一系列的技術措施，通過嚴格的質量管理與全生命周期的程序控制，達到實現避免故障、排除故障及一定程度上容許故障的目的。
　　
　　·IEC61508共有8個部分，即:
　　
　　·IEC61508-O:功能安全和IEC61508;
　　
　　·IEC61508-l:一般要求；
　　
　　·IEC61508-2:電氣/電子/可編程電子安全相關系統的要求；
　　
　　·IEC61508-3:軟件要求；
　　
　　·IEC61508-4:定義和縮略語；
　　
　　·IEC61508-5:確定安全完整性等級的方法示例；
　　
　　·IEC61508-6:IEC61508-2和IEC61508-3的應用指南；
　　
　　·IEC61508-7:技術和措施概述。
　　
　　在不同應用領域更細化和具體實現功能安全，又開發了進一步的規范，如:
　　
　　·實現機械功能安全要求的基本規范IEC62061;
　　
　　·實現過程功能安全要求的基本規范IEC61511;
　　
　　·實現核電功能安全要求的基本規范IEC61513;
　　
　　·實現醫療設備的功能安全要求的基本規范IEC60601;
　　
　　·實現鐵道運輸安全的規范EN50128;
　　
　　二、控制系統功能安全的基本概念
　　
　　安全系統的關鍵性分多個層次:
　　
　　·安全關鍵（Safety-eritiCal）系統:單個缺陷或失效會造成危險的故障，如核電站原子反應堆的停堆系統。
　　
　　·安全相關（Safety-relevant）系統:單個缺陷或失效與第二個缺陷或失效會造成危險的故障，如石化行業的安全儀表系統。
　　
　　·非安全相關（interferenCe-free）系統:即使多個缺陷或失效也不致造成危險的故障。
　　
　　對安全要求zui高的安全關鍵系統，必然為實現其安全要求而zui耗費時間、成本zui高，認證的過程和程序zui復雜。對安全的要求相對較低的安全相關系統，以及對安全要求更低的非安全相關系統，相應在時間、成本和認證所耗費的努力逐級遞減。
　　
　　在IEC61508的標準中，對石化和化工行業廣泛應用的安全相關系統有著嚴格的定義和要求:
　　
　　·必須在受控裝置EUCI高近風險或危險狀態情況下，能執行所要求的安全功能，使EUC達到或保持安全狀態；
　　
　　·依靠安全相關系統本身，或與其它E/E/PE安全相關系統、其它技術的安全相關系統或外部風險降低設施共同作用，達到所要求的安全功能必需的安全完整性。例如圖2所示的一個化工廠常見的加熱攪拌系統，除了用圓圈標出的是一個安全儀表系統（SIS）而外，安全閥就是使用機械保護的安全系統，它們配合使用達到必需的安全完整性。
　　
　　這將安全相關系統在工廠預防和減災中的作用明確規定如下:首先，由安全相關系統與外部風險降低設施共同作用，使受控設備達到必要的風險降低量，以滿足所要求的允許風險。其次，安全相關系統是在接受命令時，采取適當的順序動作防止EUC進入危險狀態。一旦安全相關系統失效，也屬于導致危險或危害的事件。第三，即使還有其他的具備安全功能的系統，但所的安全相關系統僅靠其本身的能力（而非其西系統）就能達到所要求的允許風險。第四，安全相關系統一般分為安全控制系統和安全防護系統，并且具有兩種操作模式。
　　
　　從安全相關系統的構成來看，它可以是EUC控制系統的一個組成部分，也可用傳感器和/或執行器與EUC接口，即可通過實現EUC控制系統中的安全功能（也可能通過分開的和獨立的附加系統）達到要求的安全完整性等級，或者利用分離的、獨立、專門的安全相關系統實現安全功能。
　　
　　這就明確告訴我們，安全相關系統的功能可能包括:用于防止危險事件發生，即安全相關系統一旦執行其安全功能，則不致發生有危險事件；用來減輕危險事件的影響，即通過減輕后果降低風險。或者同時具有上述的組合功能。人也可作為安全相關系統的一部分，例如，人可以接收來自可編程電子裝置的信息，并通過該裝置按接收信息要求執行安全動作。
　　
　　安全相關系統包括執行安全功能所需的全部硬件、軟件以及支持服務（如電源、傳感器和其它輸入裝置、執行器和其它輸出裝置也包括在安全相關系統中）。
　　
　　安全相關系統的技術基礎范圍可以十分廣泛，包括電氣、電子、可編程電子、液壓和氣動等。
　　
　　由于在工廠安全保護防災的體系結構中對不同的裝置、系統，甚至系統內的各個子系統或部件的安全要求常常有很大差異，因此，IEC61508標準允許對一個系統的子系統和部件進行獨立的評估。所以，我們在談論功能安全時要嚴格區分所指的對象是系統，還是構成系統的部件或子系統。
　　
　　三、控制系統的安全完整性及其等級
　　
　　安全完整性是指在規定的條件下、規定的時間內，安全相關系統成功地實現所要求的安全功能的概率。*，控制系統由構成其系統的各種硬件（控制系統裝置、現場儀表、通信網絡等等）以及執行控制要求和功能的軟件綜合而成，因此控制系統的安全完整性由硬件的安全完整性和系統的安全完整性組成。硬件安全完整性是在危險失效模式中對應于安全相關系統安全完整性的硬件隨機失效的那一部分，一般可以通過所要求的硬件安全功能失效率予以量化；而系統安全完整性則是指在危險失效模式中對應于安全相關系統安全完整性的系統失效的部分（包括軟件失效）。控制失效與避免失效涉及設計、操作模式等諸多環節。顯然，硬件隨機失效和系統失效的機制不同，控制失效的方法也不同（見圖3）。
　　
　　在安全相關系統中，安全完整性的要求用4個離散的等級予以劃分，即SIL4,SIL3,SILZ和SILI。安全完整性的等級越高的安全相關系統，其執行所要求的安全功能的概率也越高。根據安全相關系統的使用方式、所要求發生的頻率，可分為低要求操作模式和高要求（或連續）操作模式。低要求操作模式對應于每年發生風險的次數多于等于1次的安全相關系統；高要求（或連續）操作模式對應于每年發生風險的次數少于1次的安全相關系統。表l是IEC615081/GB/T20438規定的低要求操作模式下的安全完整性的目標失效概率和目標風險降低因子，表2是高要求（或連續）操作模式的安全完整性的目標失效概率。SIL3被認為是單個可編程系統中可達到的風險降低的zui高等級。
　　
　　四、安全系統的多樣性（diverSity）原則
　　
　　安全系統可以采取多樣性原則克服可能發生的故障，或設計分析中存在的不確定性。多樣性是指用不同方法執行所要求同一功能。例如:可用不同的物理方法或不同的設計途徑來達到多樣性。
　　
　　多樣性分為:①信號多樣性；②功能多樣性；③設備多樣性；④軟件多樣性（如指令運算的多樣性）；⑤人員多樣性等等。其中較為常用和有效的是信號多樣性和功能多樣性。
　　
　　對所采用的多樣性措施是否適當應加以論證。為了保證能切實執行多樣性，對設備的多樣性或儀表控制系統的軟件多樣性所進行的論證，必須擴展到這些設備的硬件、軟件部件，如實時操作系統RT0S。圖4是57-400F運用指令運算的多樣性和時間冗余來提高安全功能的可靠性。操作數A、B在CPUI進行“與”運算，結果為C;A、B經過編碼變成字A、B，在CPU2中做“或”運算，結果為D=/C。在比較器中進行比較運算，僅當D特/C時輸出停機信號。
　　
　　再如某核電站的緊急停堆系統由兩個*獨立的系統構成。其安全控制系統由不同的供應商提供。一個停堆控制系統采用安全PLC系統，由3個獨立的3機冗余表決的分系統（D、E、F）組成（見圖5）。每個分系統都具備停堆功能，但其停堆輸出還要送給3取2的繼電器硬邏輯進行表決，zui終給出停堆信號口該安全PLC系統硬件平臺配有操作系統，運用符合工業控制編程語言的標準IEC61131-3所規范的功能塊圖語言（FBD）編制應用軟件。這套停堆控制系統采用T綜合法（IntegratedApproach）設計。
　　
　　值得注意的是，為了實現安全系統的機理多樣性，還設置了另一套*不同機理的停堆系統，通過將有害的中子吸收劑（poison）注入反應堆中的慢化劑（moderator）的方法進行停堆控制。這一停堆控制系統采用沒有操作系統的工控機硬件平臺，安全控制軟件運用高安全的具有子集的MODULA-2語言編寫。這一套系統使用的是另一種設計方法一合理設計流程法（rationaldeSignProCeSS），用確定離子室記錄的功率信號的合理性來檢查異常差錯信息。由此可見，在要求*的安全關鍵系統中充分運用了多樣性的原則，有:機理的多樣性、設計方法的多樣性、設備的多樣性、編程語言的多樣性，這樣就從系統的層面上把同時發生差錯的概率降至盡可能的小。
　　
　　五、重視處理假事件
　　
　　各種安全系統（包括緊急停車系統ESD）如果對假事件作出響應，造成非計劃停車，不但要付出高昂代價，而且在大多數情況下具有危險性。大量的假報警還會導致操作人員產生矛盾心理，以至于對危險的真報警都不予理會，或者反映很慢。
　　
　　產生假事件的原因:①現場設備的硬件故障，如壓力開關、電磁閥的線圈或常閉觸點存在高電阻，PLC的I/O模塊有故障，現場設備中電子器件有故障，熱電偶斷偶，熱電阻斷線等，這些明顯的設備故障都會引發假事件。②一些公用故障如電源、氣源故障也會引發假事件。③缺乏維護，不及時對工作有缺陷的儀表、傳感器進行測試、校驗，是引發假事件的重要原因。
　　
　　下面討論信號多樣性問題。看一個用3個浮球液位開關測量液位的簡單例子（圖6）。我們可以有4種配置。采用單信號、雙信號還是三信號更有利于安全和可靠的平衡呢？概括地說:采用單機（單信號）系統不安全且不可靠，在故障安全（假事件）或危險方面存在50/50的概率；采用雙機（雙信號）系統配置為二取一（1002），可能較安全，但存在高的假故障率；雙機（雙信號）系統配置為二取二（2002），由假事件引起的故障率較低，但安全性差；三機（三信號）冗余系統為三取二（2003），提供可以接受的安全與可靠的平衡。
　　
　　顯然，SlS/ESD不能選擇單機（單信號）系統。選用雙機（雙信號）系統，在一定程度上可達到安全和可用性。二取一（1002）安全性較好，但可靠性及假事件的影響大；二取二（2002）可靠性較好，安全性卻較差。即使雙機（雙信號）系統具有很好的自診斷性能，可以確定采用哪個通道或處理器故障，將壞的通道或處理器剔除，但這時雙機系統降格為單機系統。三取二（2003）*的優點是不考慮哪個通道發生故障，是怎么發生故障的；也不*依靠自診斷來確定哪個通道投用。其亮點在于它僅要求所接收到的信息。三取二表明，若有一個信號不同于另外兩個信號，立即報警，而這兩個信號相同的通道處于安全工作狀態。
　　
　　從圖6所示的例子可知，如果流程要求用于液位測量的儀表每年只能發生1次故障，而且每半年對浮球開關進行一次維護測試，那么對于不同的浮球液位開關配置，因故障造成危險的年概率如表3所示。
　　
　　六、軟件的可靠性難以量化
　　
　　軟件可靠性的基本問題是:①軟件不受物理故障的影響。隨著硬件元器件的可靠性越來越高，并可以采用冗余技術，因而安全問題的矛盾集中到了軟件，以至于今天我們看到大多數的系統失效源自軟件。失效常常由于一些非明顯的事件組合造成，而不是由于機械應力超過一定程度造成。而這些非明顯因素往往事先沒有估計到，所以在軟件的編制中考慮不到。②軟件是由人來設計的，軟件的設計不可能面面俱到，總有些因素在設計時沒有考慮到，因此，設計的缺陷導致軟件的故障。③數字系統本質上是非連續的，所以輸入對輸出的映射一定是不連續的。④軟件建立在模型化和測試的基礎上，這些工作都是人在做的。人難免犯錯誤，所以影響軟件的可信度。
　　
　　因為以上這些不可避免的問題，可以得出軟件的可靠性難以量化的結論。另外，從趨勢上講，軟件和人為因素導致失效、事故和停機的比例越來越高。因為現在對軟件的依賴越來越高，軟件變得越來越復雜，因而難以控制。人犯錯誤不可避免。硬件失效可能是系統失效的原因，系統的失效會引起軟件的失效。有鑒于此，要保證工業控制軟件的功能安全就不得不依賴于對軟件進行嚴格的驗證和確認。
　　
　　七、工業控制軟件的功能安全概念和方法
　　
　　IEC6508-1規定了整體安全生命周期的16個階段，包括:概念，整體范圍定義，危險和風險分析，整體安全要求，安全要求分配，整體操作和維護計劃編制，整體安全確認計劃編制，整體安裝和試運行計劃編制，E肥尸E安全相關系統:實現，其他技術安全相關系統:實現，外部鳳險降低設施:實現，整體安裝和試運行，整體安全確認，整體操作維護和修理，整體修改和改型，停用及處理。與軟件相關的是第9階段“E/E/PE安全相關系統:實現”
　　
　　在IEC615O8-3中詳細地規定了執行安全功能的軟件如何滿足功能安全的要求。它規范的工控軟件的功能安全問題包括以下方面:軟件質量管理系統，軟件安全生命周期要求，軟件功能安全評估。它給出的是在軟件的安全生命周期的各個階段應該滿足什么要求，以及如何來驗證工控軟件達到了功能安全的標準。IEC61508-3的突出貢獻在于制訂了一整套完整的開發程序和一系列技術措施，通過嚴格的質量管理與全生命周期的控制程序，實現避免故障、檢測故障和排除故障，以及容許存在故障，從而保證軟件的安全完整性能。總之，IEC61508-3給出了在安全相關系統的軟件編制時應遵循哪些規范就能夠達到功能安全的要求。這好比它編織了安全軟件開發的“鳥籠”，以及在“鳥籠”里飛必須遵守的規則和約束；一旦飛出“鳥籠”就不能保證軟件的安全。但它并沒有具體規定工控軟件在選用編制系統軟件和編制應用軟件時，應該如何選擇適當的編程語言、指令集和數據類型，就可以從基礎上保證軟件的功能安全性。這些問題有些可以通過IEC61508-6（IEC61508-2和IEC61508-3的應用指南）和IEC61508-7（技術和措施概述）找到相應的具有實用性的參考規定和資料，有些就必須再進一步查找其它圍繞不同應用領域的工業控制軟件的功能安全的規范，如美國核管制委員會NRC發布的《核電站軟件語言導則》、PLCopen組織發布的在IEC61131-3的開發環境下有關機械功能安全的規范《SafetySoftwareTechnioalSpecification》等等。
　　
　　*，安全相關系統包括硬件、軟件，軟件必須運行于硬件系統環境中才能實現其價值和功能，在完成系統的功能安全時，一定要認識這二者之間的關系。通過圖7所揭示的IEC61508-3與IEC61508-2的關系就能一目了然:IEC61508-2是總體，IEC61508-3只是局部。盡管它們可能是由不同的團隊獨立開發，但zui終還是要集成起來經過總體檢驗，才能夠判斷是否滿足安全要求。軟件的安全完整性等級采用表1低要求操作模式下的安全完整性的目標失效概率劃分。達到SIL4等級的軟件相當于每1.14年至11.4年之間發生1次失效。
　　
　　八、安全系統的軟件構成
　　
　　與控制系統的軟件構成一樣，安全系統的軟件也包括系統軟件和應用軟件兩部分（見圖8）。它們分別用全可變語言（fUnvariabilitylangUage,FVL）和有限可變語言（limitedvariability1angUage,LVL）編寫（見圖7）。這些概念都是將軟件引入功能安全時建立起來的。
　　
　　什么是全可變語言呢？其實此類語言就是計算機編程人員廣泛使用的語言，它提供實現各種功能和應用的能力。典型的利用全可變語言的系統就是通用計算機。在過程工業中，只有在嵌入式軟件（一般指固件或系統軟件）中才使用全可變語言，極少在應用程序中使用。ADA、C、C++、指令表IL、Pasoal、Java、SQL均屬于全可變語言。
　　
　　有限可變語言在IEC61508-4中定義為:在工業和商業可編程電子控制器中使用且范圍局限于應用程序的文本的或圖形的軟件編程語言。例如:引自IEC61131-3和其它標準或規范的有限可變語言，用來編寫PLC系統的應用程序。它們分別是梯形圖語言LD；布爾代數語言:帶有增加某些記憶指令能力的，基于布爾運算符（如AND、OR和NOT）的低級語言；功能塊圖語言FBD:除布爾運算符外，可使用更復雜的功能，如數據傳輸文件、塊傳輸讀/寫，移位寄存器和序列發生器指令等；順序功能圖語言SFC:有順序之程序的圖形表示，由相互的步驟、動作和帶轉換條件的定向連接線構成。
　　
　　九、軟件功能安全對編程語言的要求
　　
　　編程語言并不是專為安全系統開發的，它們在出現安全軟件的概念之前就發展了很長的時間。所以要用FVL和LVL完成安全系統的軟件編寫，首先必須對這些語言和用它們編寫的程序提出要求和進行評估，以確定在什么條件下使用這些語言就能確保安全軟件完成其保證功能安全的任務。
　　
　　從另一方面來看，由于嵌入式系統已滲透到各行各業，這些年來，凡是對安全有重要要求的行業都很關注這個問題，制定了各自的規范。例如汽車行業建立了汽車工業軟件可靠性協會MISRA，發布了專門用在汽車行業的C++語言的子集MISRAC++。美國核管制委員會NRC早在1996年就發布了《核電站軟件語言導則》，之后97年又公布了其修正版NUREG/CR6463Rev.1。因為其性，直至現在它已成為安全軟件的經典規范。不僅僅是核電，其它行業的軟件安全問題也經常以此作為引經據典的文獻。
　　
　　在美國的核管制委員會發布了《核電站軟件語言導則》NUREG/CR6463Revl中，對用語言編寫的用于安全系統的軟件進行了安全評述，著重指出以往發現的軟件安全性問題和缺陷，從對應用重要性的理解、設計的方法論、學科發展和測試等方面加以闡述。
　　
　　NUREG/CR6463Revl將軟件安全的屬性按三級架構加以分類和編排:*屬性、中間屬性和基本屬性，如圖9所示。
　　
　　軟件的可靠性屬性是在所規定的條件下軟件的可預測、且恒定一致的性能。由于軟件的可靠性屬性旨在減少在軟件開發實現期間可能被導入源代碼而造成誤操作的故障，所以此*屬性對安全來說是很重要的。
　　
　　軟件的魯棒性是在異常條件或事件下，安全系統的軟件以一種可接受的方式進行操作的能力。由于它加強了軟件處理例外情況、從內部故障中恢復，以及阻止因異常環境而致使故障傳播的能力，因此此*屬性也很重要。
　　
　　軟件的可追溯性表現為:①對源代碼和所引用的程序庫部件的源頭進行檢查和識別；②通過對開發過程的可行性進行檢查，來驗證已執行的代碼在其開發過程中是否按規范的方法完成其實現；③審視代碼與高一級的設計文檔相關聯的能力。此屬性之所以重要是因為這將便于對軟件進行驗證和認證（V&V），這是軟件質量保證的另一方面。
　　
　　軟件的可維護性是在軟件交付使用后若需對源代碼做改動時，導致將故障引入的可能性減少的必要手段。此屬性之所以對安全來說很重要，是因為在對軟件進是因為在對軟件進行適應、校正或完善期間可以盡量減少可能發生的誤操作的故障。根據IEEE所給出的規定，軟件可靠性是在軟件編制、調試和執行運行全過程的環境下，既可以是在所定義的時間間隔內和所定義的條件下成功執行的幾率，也可以是按照命令成功操作的幾率。軟件執行完成是其對于系統存貯器和程序邏輯恰當行為的結果。這意味著軟件所產生的適時輸出是編程人員對所使用的語言結構和運行期間環境特性理解的函數。因此可靠性的中間屬性包括:存貯空間利用可預測性（軟件不致造成處理器會向非預期的或不允許存貯空間進行存取的高概率）；控制流可預測性（處理器按編程員預期的順序執行指令的高概率）；時序可預測性（軟件在所定義的運行環境下滿足響應時間和處理能力約束的高概率）；數學結果或邏輯結果可預測性（軟件在所定義的運行環境下產生編程員所預期結果的高概率）。詳見圖10。
　　
　　所謂軟件魯棒性是指在異常或其他未曾預計的情況下軟件繼續執行的能力。魯棒性的同義詞是耐久性（SUrviVability）。對安全系統而言魯棒性之所以重要是因為在一個意外或偏離額定工況時會發生未曾預料的事件，在這樣的情況下軟件持續的對系統監控和控制的能力仍能有效作用。軟件魯棒性的中間屬性和基礎屬性見圖11。
　　
　　軟件的可追溯性是指與軟件設計相比較，安全軟件的那些支持其正確性和完整性驗證的屬性。可追溯性的基礎屬性有:可讀性（這也是可維護性的屬性），內嵌函數的可控的使用，編譯庫的可控使用。
　　
　　軟件的可維護性是為了有效減少在對軟件進行修改時可能引入的差錯。會影響安全的與可維護性有關的中間屬性（見圖12）包括:可讀性一便干項目人員對軟件的理解的軟件屬性；數據的抽象一對于那些代碼被劃分和模塊化的區域，這樣做可以使在修改軟件時意想不到的副作用和次生的影響減至zui小；函數的內聚性一對代碼中的軟件元素給予設計水平的函數適當的存貯地址；可移植性一避免一種語言的非標準函數對安全的重大威脅；可塑性一將可能修改的代碼區與軟件代碼的其余部分隔離開。
　　
　　十、編程語言實現軟件功能安全的方法
　　
　　在NRC的NUREG/CR6463Rev.1完整版本中給出了將9種編程語言（Ada,Ada95,C/C++,PaSCal,PL/M,IEC61131-3規定的梯形圖、順序功能圖、結構化文本和功能塊圖）用于安全系統時，應該關注它們特定的存在問題和如何加以克服注意點。譬如，對于C語言來說，是其指針的初始化問題；對于IEC61131-3所規范的編程語言，則應關注其時序、正常運行的監控，以及故障處理等問題。
　　
　　從*屬性中的可靠性、中級屬性中的可預測性的控制流和基礎屬性中的在使用前變量的初始化這三方面導出對指針初始化的指導原則。所有的變量和指針在使用前都應該初始化。C語言支持通過說明來初始值的方式進行初始化，但并不要求所有的對象（指變量、數據結構或數組）進行初始化。在若干情況下，一個對象的初始化不僅要為對象的存貯地址一個特定的位的組合值，而且還要采取特殊的動作來為對象的生命（例如為對象賦予對應的源）進行平滑初始化。在C++中，可能要考慮任意相關數據作為對象，并提供構造數據組一個實例的工具。這樣便會以系統的方式破壞數據組當前的實例。
　　
　　考慮到上述情況，必須對初始化提出以下導則:①不要對超出其說明范圍的變量自動使用指針。存貯在指針的值對一個自動變量會包含超出其函數范圍的無用輸入。②指針的初始化，初始化問題也會在指針中發生。在安全系統中所有C語言中的指針變量，其初值都應該為NU11；所有C++中的指針變量，其初值都應該為0。在被使用之前，指針應對一個有效值予以測試。當一個指針被定義時，它沒有一個地址與其相關聯。使用一個未初始化的指針，會造成重寫未曾預想到的指針的存貯地址。錯誤地重寫存貯內容會引起嚴重的問題，包括對系統的崩潰。③要確保每一個指針的說明間接的運算符都是存在的。每個指針都應該有一個間接運算符（*）。
　　
　　IEC61131-3所定義的5種語言除指令表語言（IL）與匯編語言相似外，其它語言都納入了NRC關于編程語言的導則中。對這些語言特定的指導原則源于魯棒性*屬性和異常處理的中間屬性。應該專注于在機組緊急停車時PLC的行為。通常此時所有的輸出均應切斷，但往往并非總是如此。一般PLC系統總是設計成在緊急停車時系統處于故障安全狀態。某些PLC在遇到這樣的情況時具有處理器能自動停止主梯形圖程序的執行，轉而執行“故障程序”的子程序。這使系統的設計者可以決定采取適當的動作，包括以一種安全的方式讓系統停下來。問題在于:IEC61131-3規范中未涉及到允許PLC系統本身包含有某種預先設計好的硬件故障程序，當檢側到一定范圍的故障條件時便會自動執行。不過，IEC61131-3允許建立非周期的任務，通過觸發適當的內部診斷信息來執行處理特定類型的出錯（I/*時降級運行模式、向操作員見面報警等）。
　　
　　對于PLC系統，在編程的設計階段就應在程序結構中考慮故障程序問題。這時必須遵從如下原則:①完整性故障程序不能依賴于檢測到程序崩潰的所有特例，因此遇到PLC的主要故障時要有針對附加措施的安全保證。②可觀察性故障程序要有狀態記錄和報警的能力。故障程序應顯性執行，不被掩蓋。③真實性檢查在啟動故障程序的情況下有可能將可以反映原來條件的程序存貯內容、數據文件或I/O狀態破壞，因此故障程序應保證在執行故障處理前將這些環境加以保存，以便事后分析。④在故障程序不起作用時的靛障安全特性萬一PLC系統的故障處理程序不起作用，系統設計仍要保證安全狀態的后備措施。
　　
　　PLC系統一般以的位和字的形式提供對應用程序的正常運行狀況的監控，這些信息包括特定任務的執行時間、I/O刷新信息、I/O操作狀態信息、電池狀態信息和其它用來確定PLC正常運行狀態的信息。遺憾的是IEC61131-3規范中對這些信息的典型值、范圍和類型并未做出規定。而安全系統恰恰應該具備這些信息，作為判斷其是否運行正常的檢查和是否需要異常處理的*的部分。
　　
　　在IEC61131-3的規范關于“任務”這節中，闡述了制造廠應向用戶提供所有任務執行的信息的zui低要求。關鍵在于由干這一問題的分類落在出錯檢查，而未能在規范中描述，于是我們也得不到這些任務執行時在運行時應以何種形式接受檢查的規定。另外，許多PLC和類似的符合IEC6113卜3的系統一般只給出每次執行所有任務的周期（即所謂的掃描周期），卻忽略了單個任務執行周期信息和標志的提供。如果因為安全原因需要在執行某個任務超時N次時必須緊急停車，在PLC現有的能力下是無能為力的。為了解決這個問題，必須讓應用程序能夠對單個任務執行其超時的檢測，并給出單任務超時的標志，這樣才能做出適當的反應。對于安全關鍵系統，監控任務超時的問題尤其要緊。必須在程序開發的檢查階段關注。
　　
　　十一、在安全系統中推薦采用的編程語言
　　
　　在IEC61508-7的附錄C.4.5中給出了適合用于安全系統的軟件編制推薦的語言（見表4），表中列舉了24種編程語言，其中適用于安全系統的軟件編制的語言共9種，它們是:屬于全可變語言FVL有5種（具有子集的ADA，具有子集的MODULA-2，具有子集的Pascal，具有子集的FORTRAN77，具有子集和編程標準并使用靜態分析工具的C）；屬于有限可變語言LVL有4種（具有定義的語言子集的梯形圖，具有定義的語言子集的功能塊圖，具有定義的語言子集的結構化文本，具有定義的語言子集的順序功能圖）。
　　
　　PLCopen組織與專業從事安全認證的機構TUV一起定義了在IEC61131-3的環境下涉及機械安全的規范《SafetySoftwareTechnicalSpecification》。其中僅規定了兩種具有定義子集的語言（功能塊圖語言FBD和梯形圖語言LD）可用于機械安全系統。