導航：安全管理網(wǎng)>> 安全論文>> 綜合安全論文>>正文

工業(yè)控制軟件功能安全的實現(xiàn)方法和評估

文檔作者：彭瑜文檔來源：上海工業(yè)自動化研究院		點擊數(shù)：	更新時間： 2021年06月05日
下載地址：點擊這里	文件大小： 519.40 KB 共7頁	文檔格式： PDF	下載點數(shù)： 1 點（VIP免費）

全屏查看

內容預覽 [文件共7頁]

本文件共7頁，如需編輯使用，請下載。

注：預覽效果可能會出現(xiàn)部分文字亂碼（如口口口）、內容顯示不全等問題，下載是正常的。

	文件大小：519.40 KB 共7頁文件格式：PDF 下載點數(shù)：1 點（VIP會員免費）

下一篇：過程工業(yè)控制系統(tǒng)及其軟件的功能安全

上一篇：工業(yè)控制系統(tǒng)安全狀況分析

文本預覽

僅提取頁面文字內容，供快速閱讀使用。

第47卷第1期
2011年2月
石油化工 自動化
AUT0MAT10N IN PETRC卜CHEMICAL INDUSTRY
Vo1．47。No．1
February，2011
工業(yè)控制軟件功能安全的
實現(xiàn)方法和評估
彭 瑜
(上海工業(yè)自動化研究院智能儀表與系統(tǒng)研究所，上海200233)
摘要：從趨勢上講，軟件和人為因素導致控制系統(tǒng)失效、事故和停機的比例越來越高。這源于現(xiàn)在對軟件的依賴越來越
高，軟件也變得越來越復雜，以至于難以在軟件的開發(fā)過程中有效地控制軟件質量、軟件的信息安全和軟件的功能安全。從介
紹控制系統(tǒng)功能安全和安全完整性的基本概念人手，闡述工業(yè)控制軟件功能安全的概念、安全完整性等級和實現(xiàn)工業(yè)控制軟件
功能安全的流程及方法，包括對編程語言和實時操作系統(tǒng)的要求和選擇。還用相當篇幅討論工業(yè)控制軟件功能安全的驗證和
確認的基本方法，指出在軟件生命周期的各個階段都要由第三方進行軟件功能安全的驗證，為保證最終軟件產品的性能，在階
段性驗證的基礎上最終通過確認來確定它是否滿足系統(tǒng)的所有要求。
關鍵詞：工業(yè)控制軟件的功能安全；軟件功能安全的認證和確認；全可變語言；有限可變語言
中圖分類號：TP273 文獻標志碼：A 文章編號：1007—7324(2011)01—0001—07
1lhe Implem entation M ethods and Evaluation for
the Functional Safety of Industrial Control Software
Peng Yu
(The Shanghai Industry Automation Research Academy，Intelligent
Instrument and System Research Institute，Shanghai，200233，China)
Abstract：By trending，the proportion of failures，faults and shutdown of control systems，caused by
software and artificial factors，has become higher and higher．That is originated from which there are
more and more dependent on software and software is becomeing more and more complex SO that it is
hard effectively to handle the quality， security and functional safety of software during software
development course． It starts with introducing the fundamentation process and methods of functional
safety of industrial control software and implementation methods， including the requirements and
selection of programming languages and real——time operating system． It is addressed to discuss
verification and validation for functional safety of industrial control software in detail．Furthermore it iS
pointed out that verification of software’S functional safety should be made by the third party in every
phase of software lifetime and verification in order to guarantee the performance of final software
products．
Keywords：functional safety of industrial control software；verification and validation for functional
safety of software；full variability language；limited variability language
1 控制系統(tǒng)功能安全的基本概念
安全系統(tǒng)從關鍵性區(qū)分可分為以下幾個層次：
a)安全關鍵(safety—critica1)系統(tǒng)：單個缺陷
或失效會造成危險的故障，如核電站原子反應堆的
停堆系統(tǒng)，高速軌道交通的安全停車系統(tǒng)。
b)安全相關(safety—relevant)系統(tǒng)：單個缺陷
或失效與第二個缺陷或失效會造成危險的故障，如
石化行業(yè)的安全儀表系統(tǒng)。
c)非安全相關(interference—free)系統(tǒng)：即使
多個缺陷或失效也不致造成危險的故障。
收稿日期：2010—12—13。
作者簡介：彭瑜(1938 )，男，1960年畢業(yè)于清華大學動力
系，上海工業(yè)自動化儀表研究所教授級高級工程師，長期從事工業(yè)
過程控制系統(tǒng)的研究開發(fā)工作，自1996年后，研究開發(fā)方向集中
在現(xiàn)場總線、工業(yè)以太網(wǎng)、MES，以及無線短程網(wǎng)的開發(fā)和工業(yè)應
用，1993年起獲得國務院特殊津貼，中國自動化學會理事，中國自
動化學會儀表和裝置專業(yè)委員會常務委員，上海市自動化學會榮
譽理事，中國儀器儀表學會專家委員會委員，PLCopen國際組織中
國委員會主席。
2 石油化工自動化 第47卷
顯而易見，對安全要求最高的安全關鍵系統(tǒng)，
必然為實現(xiàn)其安全要求而耗時最多、成本最高，認
證的過程和程序最復雜。對安全要求相對較低的
安全相關系統(tǒng)，以及對安全要求更低的非安全相關
系統(tǒng)，相應在時間、成本和認證等方面的耗費會逐
級遞減。
在IEC 61508的標準中，對石化和化工行業(yè)廣
泛應用的安全相關系統(tǒng)有著嚴格的定義和要求：
必須在受控裝置(EuC)臨近風險或危險狀態(tài)情況
下，能執(zhí)行所要求的安全功能，使EUC達到或保
持安全狀態(tài)；依靠安全相關系統(tǒng)本身，或與其他E／
E／PE安全相關系統(tǒng)、其他技術的安全相關系統(tǒng)或
外部風險降低設施共同作用，達到所要求的安全功
能必須的安全完整性。
這將明確規(guī)定安全相關系統(tǒng)在工廠預防和減
災中的作用如下。
a)由安全相關系統(tǒng)與外部風險降低設施共同
作用，使受控設備達到必要的風險降低量，以滿足
所要求的允許風險。
b)安全相關系統(tǒng)在接受命令時，采取適當
的順序動作防止EUC進入危險狀態(tài)。一旦安
全相關系統(tǒng)失效，也屬于導致危險或危害的
事件。
c)即使還有其他的具備安全功能的系統(tǒng)，但
所指定的安全相關系統(tǒng)僅靠其本身的能力(而非其
他系統(tǒng))就能達到所要求的允許風險。
d)安全相關系統(tǒng)一般分為安全控制系統(tǒng)和安
全防護系統(tǒng)，并且具有兩種操作模式。
從安全相關系統(tǒng)的構成來看，它可以是EUC
控制系統(tǒng)的一個組成部分，也可通過傳感器和／
或執(zhí)行器與EUC有接口，即可通過實現(xiàn)EUC控
制系統(tǒng)中的安全功能(也可能通過分開的和獨立
的附加系統(tǒng))達到要求的安全完整性等級，或者
利用分離的、獨立、專門的安全相關系統(tǒng)實現(xiàn)安
全功能。
人也可作為安全相關系統(tǒng)的一部分，例如，人
可以接收來自可編程電子裝置的信息，并通過該裝
置按接收信息要求執(zhí)行安全動作。安全相關系統(tǒng)
包括執(zhí)行安全功能所需的全部硬件、軟件以及支持
服務(如電源、傳感器和其他輸入裝置、執(zhí)行器和其
他輸出裝置)。
2 安全完整性等級
安全完整性是指在規(guī)定的條件下和規(guī)定的時
間內，安全相關系統(tǒng)成功地實現(xiàn)所要求的安全功能
的概率。眾所周知 ，控制系統(tǒng)由構成其系統(tǒng)的各種
硬件(控制系統(tǒng)裝置、現(xiàn)場儀表、通信網(wǎng)絡等)以及
執(zhí)行控制要求和功能的軟件綜合而成，因此控制系
統(tǒng)的安全完整性由硬件的安全完整性和系統(tǒng)的安
全完整性組成。
硬件安全完整性是在危險失效模式中對應于
安全相關系統(tǒng)安全完整性的硬件隨機失效的那一
部分，一般可以通過所要求的硬件安全功能失效率
予以量化；而系統(tǒng)安全完整性則是指在危險失效模
式中對應于安全相關系統(tǒng)安全完整性的系統(tǒng)失效
的部分(包括軟件失效)。控制失效與避免失效涉
及設計、操作模式等諸多環(huán)節(jié)。顯然，硬件隨機失
效和系統(tǒng)失效的機制不同，控制失效的方法也不
同，如圖1所示。
可以通過改變設計、生產過程、操
作模式、操作指令或其他影響因子，
來消除原因確定的失效
l
避免失效
控制失效
l
估算由于隨機硬
件失效造成的每
個安全功能的失
效概率
圖1 控制系統(tǒng)失效機理
在安全相關系統(tǒng)中，安全完整性的要求用4個
離散的等級予以劃分，即SIL4，SIL3，SIL2和
SILl。安全完整性等級越高的安全相關系統(tǒng)，其
執(zhí)行所要求的安全功能的概率也越高。
根據(jù)安全相關系統(tǒng)的使用方式、所要求發(fā)
生的頻率，可分為低要求操作模式和高要求(或
連續(xù))操作模式。低要求操作模式對應于每年
發(fā)生風險的次數(shù)多于或等于1次的安全相關系
統(tǒng)；高要求(或連續(xù))操作模式對應于每年發(fā)生
風險的次數(shù)少于1次的安全相關系統(tǒng)。表1是
IEC 61 5081／GB／T 20438規(guī)定的低要求操作模
式下的安全完整性的目標失效概率和目標風險
降低因子；表2是高要求(或連續(xù))操作模式的
安全完整性的目標失效概率。SIL3被認為是單
個可編程系統(tǒng)中可達到的風險降低的最高等
級。要達到SIL4，必須采用多重冗余的可編程
系統(tǒng)。
表1 低要求操作模式下的安全完整性的目標平均
失效概率和目標風險降低因子
第1期 彭 瑜．工業(yè)控制軟件功能安全的實現(xiàn)方法和評估
表2 高要求(或連續(xù))操作模式的
安全完整性的目標平均失效概率
3 軟件的可靠性難以精確量化
a)軟件不受物理故障的影響。隨著硬件元器
件的可靠性越來越高及冗余技術的使用，安全問題
的矛盾主要集中到了軟件，以至于大多數(shù)的系統(tǒng)失
效源自軟件。失效常常由于一些非明顯的事件組
合造成，而不是由于機械應力超過一定程度造成。
而這些非明顯因素往往事先沒有估計到。
b)設計的缺陷導致軟件的故障。軟件是由人
來設計的，軟件的設計不可能面面俱到，總有些因
素在設計時沒有考慮到。例如某廠的工程計算機
無故障運行了兩年，卻在一個新來的操作員值班時
進行一個報警的確認后，屏幕發(fā)生死屏。將系統(tǒng)重
新啟動，一切恢復正常。同類系統(tǒng)已經(jīng)在現(xiàn)場安裝
使用了500余套，具有1 200多萬小時的正常運
行。為慎重起見，測試工程師向曾經(jīng)發(fā)生故障時當
班的控制系統(tǒng)操作員進行調查結果發(fā)現(xiàn)這個操作
員操作鍵盤的速度極快，由此發(fā)現(xiàn)了導致系統(tǒng)失效
的根源。原來在報警消起鍵按下32 ms內按下報
警確認鍵會引發(fā)一個例行程序覆蓋某一內存區(qū)，因
而造成計算機崩潰。顯而易見，這一故障屬于功能
性故障。
0)數(shù)字系統(tǒng)本質上是非連續(xù)的，所以輸入對
輸出的映射一定是不連續(xù)的。
d)軟件建立在模型化和測試的基礎上，也許
永遠也難以把所有可能的失效原因都事先考慮周
全。人難免犯錯誤，所以影響軟件的可信度。
4 軟件的功能安全概念和方法
IEC 61508—1規(guī)定了整體安全生命周期的16個
階段，包括：概念，整體范圍定義，危險和風險分
析，整體安全要求，安全要求分配，整體操作和維護
計劃編制，整體安全確認計劃編制，整體安裝和試
運行計劃編制，E／E／PE安全相關系統(tǒng)及實現(xiàn)，其
他技術安全相關系統(tǒng)及實現(xiàn)，外部風險降低設施及
實現(xiàn)，整體安裝和試運行，整體安全確認，整體操作
維護和修理，整體修改和改型，停用及處理。與軟
件相關的是第9階段“E／E／PE安全相關系統(tǒng)及
實現(xiàn)”
IEC 61508—2和IEC 61508—3是評估工控軟
件符合功能安全的標準。其中IEC 61502—2是總
體，IEC 61508—3是局部，最終還是要集成起來經(jīng)
過總體檢驗，才能判斷是否滿足安全要求，其關系
如圖2所示。IEC61508—3詳細地規(guī)定了執(zhí)行安
全功能的軟件如何滿足功能安全的要求。包括以
下方面：軟件質量管理系統(tǒng)，軟件安全生命周期要
求，功能安全評估。它給出在軟件的安全生命周期
的各個階段應該滿足什么要求，以及如何來驗證工
控軟件達到了功能安全的標準。
E／E／PE系統(tǒng)
設計要求規(guī)范
IEC
6l 508—3
范圍 軟件安全
要求
—丁
軟件設
計開發(fā)
— — I IEC
E／E／PE l I61 508—2
丕 塑l I范圍
硬件安全要求規(guī)范
面訂
可編程硬件{l非可編程硬
設計開發(fā)I l件設計開發(fā)
可編程設備集成
＼(硬件和軟件)
E／E／PE
系統(tǒng)集成
圖2 IEC 61508—3與IEC 61508—2的關系
IEC 61508—3的突出貢獻在于制訂了一整套完
整的開發(fā)程序和一系列技術措施，通過嚴格的質量
管理與全生命周期的控制程序，實現(xiàn)避免故障、檢
測故障和排除故障，以及容許存在故障，從而保證
軟件的安全完整性能。但是并沒有具體規(guī)定工控
軟件在選用／編制系統(tǒng)軟件和編制應用軟件時，應
該如何選擇適當?shù)木幊陶Z言、指令集和數(shù)據(jù)類型，
就可以從基礎上保證軟件的功能安全性。這些問
題有些可以通過IEC 61508—6(IEC 61508—2和
IEC 61508—3的應用指南)和IEC 61508—7(技術
和措施概述)找到相應的具有實用性的參考規(guī)定和
資料，有些就必須再進一步查找其他圍繞不同應用
領域的工業(yè)控制軟件的功能安全的規(guī)范，如美國核
管制委員會NRC發(fā)布的《核電站軟件語言導則》、
PLCopen國際組織發(fā)布的在IEC 61131—3的開發(fā)
環(huán)境下有關機械功能安全的規(guī)范《Safety Software
Technical Specification}等。
5 工控軟件功能安全的驗證和確認概念
5．1 驗證的概念
按照IEC 61508—4的定義，驗證(verification)是
通過檢查和提供客觀證據(jù)來證實對系統(tǒng)或子系統(tǒng)、
部件的要求已被滿足。例如：驗證活動包括為保
證符合階段要求和目的，考慮該階段的特定輸入，
對其輸出(來自所有安全生命周期階段的文檔)進
行復審；設計復審；對設計的產品進行測試以保證
按它們的規(guī)范工作；對系統(tǒng)不同部分分步組裝在一
4 石油化工自動化 第47卷
起后的整體進行集成測試，并進行環(huán)境測試以保證
所有部分按規(guī)定方式在一起工作。
5．2 確認的概念
按照IEC 61508—4的定義，確認(validation)
通過檢查和提供客觀證據(jù)來證實某一特定預期用
途的特殊要求被滿足。確認是一個證明所考慮的
安全相關系統(tǒng)在安裝前后全面滿足該系統(tǒng)的安全
要求規(guī)范的活動。比如軟件確認意味著用提供客
觀證據(jù)和檢查的方法來證明軟件滿足軟件安全要
求規(guī)范。
5．3 軟件的驗證和確認
軟件的驗證是在軟件生命周期的各個階段，
按照其生命周期的特定階段的規(guī)范和要求，通過
分析和／或測試去查證其活動和結果是否正確。
在每個階段都有其特定的輸入去檢驗該階段的
成效或成果，如其結果能滿足各方面的目的和要
求視為通過。一般來說，驗證的測試方法采用白
盒測試方法。確認則是在階段性驗證的基礎上
保證了最終軟件產品的性能，只要通過黑盒測試
方法來最終確定它是否滿足系統(tǒng)要求。所以可
以這樣認為，驗證貫穿著軟件生成的每個階段，
確認則是軟件完成后必須接受的最終裁定。由
具有安全認證資質的第三方(例如權威的德國安
全認證機構TUV)完成驗證和確認(通常簡稱
V&amp;amp;V)的工業(yè)控制軟件，就可以投入安全系統(tǒng)的
使用。功能安全要求的軟件開發(fā)生命周期驗證
和確認全過程的相互關系(V模型)如圖3所示。
按照IEC 61508—3確保軟件開發(fā)質量的流程如
圖4所示。
圖3 軟件開發(fā)生命周期驗證和確認
全過程的相互關系(V模型)
順便指出，軟件的安全完整性等級是按照表1
低要求操作模式下的安全完整性來劃分的。達到
SIL4等級的軟件相當于每1．14a至11．4a之間發(fā)
生1次失效。之所以采取低要求操作模式而不是
高要求操作模式來劃分軟件的安全完整性等級，正
是基于軟件的可靠性難以精確量化一節(jié)中已敘述
的問題，在保證功能安全的性能上，軟件較之硬件
更困難，以至于不得不調低風險降低因子的要求。
從安全計劃編制獲得E／E／PES安全要求規(guī)范和相關部分
確定軟件結構
結 筵 桑 ．1 霽 喜
開始編制軟件驗證和確認計劃
設計、開發(fā)、驗證或測試軟件
． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ． ．[．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．一
編制操作和維護規(guī)程 在目標硬件上集成經(jīng)驗證過的軟件
執(zhí)行軟件確認
把軟件和文檔提供給系統(tǒng)工程師
軟件的維護及修改
圖4 按照IEC 61508—3確保
軟件開發(fā)質量的流程
6 安全系統(tǒng)的軟件構成
與控制系統(tǒng)的軟件構成一樣，安全系統(tǒng)的
軟件也包括系統(tǒng)軟件和應用軟件兩部分(如圖5
所示)。它們分別用全可變語言FVL(Full
Variability Language)和有限可變語言LVL
(Limited Variability Language)編寫。這些概念
都是將軟件引入功能安全時建立起來的。
軟件開發(fā) 安全標準要求 安全運行期
圖5 功能安全用編程語言的構成
注：*一IEC 62061，ISO 13849—1或!EC 61511
7 軟件功能安全對編程語言的要求
編程語言并不是專為安全系統(tǒng)開發(fā)的，它們在
出現(xiàn)安全軟件的概念之前就發(fā)展了很長的時間。
所以要用FVL和LVL完成安全系統(tǒng)的軟件編寫，
首先必須對這些語言和用它們編寫的程序提出要
求和進行評估，以確定在什么條件下使用這些語言
就能確保安全軟件完成保證功能安全的任務。
第1期 彭 瑜．工業(yè)控制軟件功能安全的實現(xiàn)方法和評估
從另一方面來看，由于嵌入式系統(tǒng)已滲透到各
行各業(yè)，這些年來，凡是對安全有重要要求的行業(yè)
都很關注這個問題，制定了各自的規(guī)范。例如汽車
行業(yè)就建立了汽車工業(yè)軟件可靠性協(xié)會MISRA，
發(fā)布了專門用在汽車行業(yè)的C++語言的子集
MISRA C++。美國核管制委員會NRC早在
1996年就發(fā)布了《核電站軟件語言導則》，之后
1997年又公布了其修正版NUREG／CR 6463
Rev．1。因為其權威性，直至現(xiàn)在它已成為安全軟
件的經(jīng)典規(guī)范。不僅僅是核電，其他行業(yè)的軟件安
全問題也經(jīng)常以此作為引經(jīng)據(jù)典的文獻。
例如，在NUREG／CR 6463 Rev．1中，對用高
級語言編寫的用于安全系統(tǒng)的軟件進行了安全評
述，著重指出以往發(fā)現(xiàn)的軟件安全性問題和缺陷，
從應用重要性的理解、設計的方法論、學科發(fā)展和
測試等方面加以闡述。該規(guī)范將軟件安全的屬性
按三級架構加以分類和編排：頂級屬性、中間屬性
和基本屬性，如圖6所示。
頂級屬性
(可靠性、魯棒性、可追溯性和可維護性)
l
l l l
中間屬性 中間屬性 中間屬性
(如：存儲空間 (如：控制流的 (如：時序的
利用的可預測性) 可預測性) 可預測性)
l
基礎屬性
(如：動態(tài)存儲
分配的最小化)
l
語言專用導則
(如：特定軟肋
的最小化)
圖6 軟件安全的三級架構屬性
根據(jù)IEEE所給出的規(guī)定，軟件可靠性是在軟
件編制、調試和執(zhí)行運行全過程的環(huán)境下，既可以
是在所定義的時間間隔內和所定義的條件下成功
執(zhí)行的幾率，也可以是按照命令成功操作的幾率。
軟件執(zhí)行完成是其對于系統(tǒng)存儲器和程序邏輯恰
當行為的結果。這意味著軟件所產生的適時輸出
是編程人員對所使用的語言結構和運行期間環(huán)境
特性理解的函數(shù)。因此可靠性的中間屬性包括：
存儲空間利用可預測性(軟件不致造成處理器會向
非預期的或不允許存儲空間進行存取的高概率)；
控制流可預測性(處理器按編程員預期的順序執(zhí)行
指令的高概率)；時序可預測性(軟件在所定義的運
行環(huán)境下滿足響應時間和處理能力約束的高概
率)；數(shù)學結果或邏輯結果可預測性(軟件在所定義
的運行環(huán)境下產生編程員所預期結果的高概率)，
如圖7所示。
存儲空間利用的可預測性ll 空制流的可預測性l l時序的可預測性
卜動態(tài)存儲分配的最 一結構最大化 盡可能少片
IL小化 一控制流復雜性的 L任務調用
內存分頁和存儲空 最小化
間對換的最小化 一變量的初始化
一子程序的進入點和
出口點只有一個
一不用賦值語句
一界面歧義最小化
一采用數(shù)據(jù)鍵人
一準確度、精度進行記錄
一排定優(yōu)先級
一避免執(zhí)行子程序產生的
狀態(tài)變化
一將求值與賦值隔開
一動態(tài)綁定最小化
圖7 軟件可靠性的中間屬性
所謂軟件魯棒性是指在異常或其他未曾預計
的情況下軟件繼續(xù)執(zhí)行的能力。魯棒性的同義詞
是耐久性(survivability)。對安全系統(tǒng)而言魯棒性
之所以重要是因為在一個意外或偏離額定工況時
會發(fā)生未曾預料的事件，在這樣的情況下軟件持續(xù)
地對系統(tǒng)監(jiān)控和控制的能力仍能有效。軟件魯棒
性的中問屬性和基礎屬性如圖8所示。
圖8 軟件魯棒性的中間屬性和基礎屬性
軟件的可追溯性是指與軟件設計相比較，安全
軟件的那些支持其正確性和完整性驗證的屬性。
可追溯性的基礎屬性：可讀性(這也是可維護性的
屬性)，內嵌函數(shù)的可控的使用，編譯庫的可控
使用。
軟件的可維護性是為了有效減少在對軟件進
行修改時可能引入的差錯。會影響安全的與可維
護性有關的中問屬性(如圖9所示)，包括：可讀
性—— 便于項目人員對軟件的理解的軟件屬性；數(shù)
據(jù)的抽象— — 對于那些代碼被劃分和模塊化的區(qū)
域，這樣做可以使在修改軟件時意想不到的副作用
和產生的影響減至最小；函數(shù)的內聚性—— 對代碼
中的軟件元素給予設計水平的函數(shù)適當?shù)拇鎯Φ?
址；可移植性—— 避免一種語言的非標準函數(shù)對安
全的重大威脅；可塑性—— 將可能修改的代碼區(qū)與
軟件代碼的其余部分隔離開。
8 編程語言實現(xiàn)軟件功能安全的方法
在NRC的NUREG／CR 6463 Rev．1完整版本
石油化工自動化 第47卷
中給出了將9種編程語言(Ada，Ada95，C／C++，
Pascal，PL／M，IEC61131—3規(guī)定的梯形圖、順序功
能圖、結構化文本和功能塊圖)用于安全系統(tǒng)時，應
該關注它們特定的存在問題和如何加以克服等注
意點。
圖9 可維護性有關的中間屬性
從頂級屬性中的可靠性、中級屬性中的可預測
陛的控制流和基礎屬性中的變量的初始化這三方
面，導出對指針初始化的指導原則。
所有的變量和指針在使用前都應該初始化。
c語言支持通過說明來指定初始值的方式進行初
始化，但并不要求所有的對象(指變量、數(shù)據(jù)結構
或數(shù)組)進行初始化。在若干情況下，一個對象
的初始化不僅要為對象的存儲地址指定一個特
定的位的組合值，而且還要采取特殊的動作來為
對象的生命(例如為對象賦予對應的源)進行平
滑初始化。在C++ 中，可能要考慮任意相關數(shù)
據(jù)作為對象，并提供構造數(shù)據(jù)組一個實例的工
具。這樣便會以系統(tǒng)的方式破壞數(shù)據(jù)組當前的
實例。
考慮到上述情況，在初始化時必須遵照以下導
則：a)不要對超出其說明范圍的變量自．動使用指
針，存儲在指針的值，對一個自動變量會包含超出
其函數(shù)范圍的無用輸人Ib)指針的初始化問題也
會在指針中發(fā)生，在安全系統(tǒng)中所有c語言中的
指針變量，其初值都應該為null；所有C++中的指
針變量，其初值都應該為0，在被使用之前，指針應
對一個有效值予以測試，當一個指針被定義時，它
沒有一個地址與其相關聯(lián)，使用一個未初始化的指
針，會造成重寫未曾預想到的指針的存儲地址，錯
誤地重寫存儲內容會引起嚴重的問題，包括引起系
統(tǒng)的崩潰；c)要確保每一個指針的說明其問接的
運算符都是存在的，每個指針都應該有一個間接運
算符(*)。
IEC 61131—3所定義的5種語言除指令表語
言(IL)與匯編語言相似外，其他語言都納入了
NRC關于編程語言的導則中。對這些語言特定的
指導原則源于魯棒性頂級屬性和異常處理的中問
屬性。應該專注于在機組緊急停車時PLC的行
為。通常此時所有的輸出均應切斷，但往往并非總
是如此，一般PLC系統(tǒng)總是設計成在緊急停車時
系統(tǒng)處于故障安全狀態(tài)。某些PLC在遇到這樣的
情況時具有處理器能自動停止主梯形圖程序的執(zhí)
行，轉而執(zhí)行“故障程序”的子程序功能。這使系統(tǒng)
的設計者可以決定采取適當?shù)膭幼鳎ㄒ砸环N安
全的方式讓系統(tǒng)停下來。問題在于：IEC 61131—
3規(guī)范中未涉及到允許PLC系統(tǒng)本身包含有某種
預先設計好的硬件故障程序，當檢測到一定范圍的
故障條件時便會自動執(zhí)行。不過，IEC 61131—3
允許建立非周期的任務，通過觸發(fā)適當?shù)膬炔吭\斷
信息來執(zhí)行處理特定類型的出錯(I／O故障時降級
運行模式、向操作員見面報警等)。
對于PLC系統(tǒng)，在編程的設計階段就應在程
序結構中考慮故障程序問題。這時必須遵從如下
原則：a)完整性，故障程序不能依賴于檢測到程
序崩潰的所有特例，因此遇到PLC的主要故障時
要有針對附加措施的安全保證．b)可觀察性，故障
程序要有狀態(tài)記錄和報警的能力，故障程序應顯性
執(zhí)行，不被掩蓋；c)真實性檢查，在啟動故障程序
的情況下有可能將可以反映原來條件的程序存儲
內容、數(shù)據(jù)文件或I／O狀態(tài)破壞，因此故障程序應
保證在執(zhí)行故障處理前將這些環(huán)境加以保存，以便
事后分析；d)在故障程序不起作用時的故障安全
特性。萬一PLC系統(tǒng)的故障處理程序不起作用，
系統(tǒng)設計仍要保證安全狀態(tài)的后備措施。
PLC系統(tǒng)一般以指定的位和字的形式提供對
應用程序的正常運行狀況的監(jiān)控，這些信息包括特
定任務的執(zhí)行時間、I／O刷新信息、I／O操作狀態(tài)
信息、電池狀態(tài)信息和其他用來確定PLC正常運
行狀態(tài)的信息。遺憾的是IEC 61131—3規(guī)范中對
這些信息的典型值、范圍和類型并未做出規(guī)定。而
安全系統(tǒng)恰恰應該具備這些信息，作為判斷其是否
運行正常的檢查和是否需要異常處理的不可或缺
的部分。
在IEC 61131—3的規(guī)范關于“任務”這節(jié)中，
闡述了制造廠應向用戶提供所有任務執(zhí)行的信息
的最低要求。關鍵在于由于這一問題的分類落在
出錯檢查，而未能在規(guī)范中描述，于是也得不到這
些任務執(zhí)行時在運行過程中應以何種形式接受檢
查的規(guī)定。另外，許多PLC和類似的符合IEC
61131—3的系統(tǒng)一般只給出每次執(zhí)行所有任務的
周期(即所謂的掃描周期)，卻忽略了單個任務執(zhí)行
周期信息和標志的提供。如果因為安全原因需要
第1期 彭 瑜．工業(yè)控制軟件功能安全的實現(xiàn)方法和評估
在執(zhí)行某個任務超時N 次時必須緊急停車，在
PLC現(xiàn)有的能力下是無能為力的。為了解決這
個問題，必須讓應用程序能夠對單個任務執(zhí)行其
超時的檢測，并給出單任務超時的標志，這樣才
能做出適當?shù)姆磻τ诎踩P鍵系統(tǒng)，監(jiān)控任
務超時的問題尤其要緊。必須在程序開發(fā)的檢
查階段關注。
9 在安全系統(tǒng)中推薦采用的編程語言
在IEC 61508—7的附錄C．4．5中給出了適合
用于安全系統(tǒng)的軟件編制推薦的24種語言，其中
適用于安全系統(tǒng)的軟件編制的語言共9種，包括：
屬于全可變語言FVI 有5種(具有子集的ADA，
具有子集的MODULA一2，具有子集的Pascal，具
有子集的Fortran77，具有子集和編程標準并使用
靜態(tài)分析工具的C語言)；屬于有限可變語言LVL
有4種(具有定義的語言子集的梯形圖，具有定義
的語言子集的功能塊圖，具有定義的語言子集的結
構化文本，具有定義的語言子集的順序功能圖)。
PI Copen國際組織與專業(yè)從事安全認證的權
威機構TUV一起定義了在IEC 61131—3的環(huán)境
下涉及機械安全的規(guī)范《Safety Software
Technical Specification)。其中僅規(guī)定了兩種具有
定義子集的語言(功能塊圖語言FBD和梯形圖語
言I D)可用于機械安全系統(tǒng)。
10 關于嵌入式操作系統(tǒng)的安全問題
隨著嵌入式設備的功能越來越趨于強大和復
雜，系統(tǒng)的開發(fā)對操作系統(tǒng)的依賴就越來越大，以
至于在嵌入式系統(tǒng)中操作系統(tǒng)成為系統(tǒng)中必不可
少的部分。作為系統(tǒng)軟件的核心，嵌入式操作系統(tǒng)
的主要作用：有效管理越來越復雜的系統(tǒng)資源；將
硬件虛擬化，使開發(fā)人員得以從驅動程序的移植和
維護中得到解脫；提供庫函數(shù)、驅動程序、工具集以
及應用程序。
與通常的操作系統(tǒng)比較，嵌入式操作系統(tǒng)的特
點：所需存儲空間小；實時性強；開發(fā)環(huán)境特殊。常
用的嵌入式操作系統(tǒng)有：VxWorks，~tcosII，QNX，
WinCE，>CLinux，ThreadX，Integrity等。
實際上軟件安全認證有多種標準，主要有兩
類，即信息安全標準和功能安全標準。信息技術
安全評估的公共標準是為安全性能、安全保證和
安全評估制定的國際標準ISO／IEC15408，它是已
被美國政府、加拿大和其他23個國家所認同的國
際標準。它將信息安全評估分成7個等級EAL
(Evaluation Assurance Leve1)。目前已評定的操
作系統(tǒng)的最高等級是EAL 6+(美國Green Hills
公司的Integrity一178B實時操作系統(tǒng))。工業(yè)功
能安全標準是IEC 61508—3。它將SIL分成4個
等級。目前已評定的操作系統(tǒng)的最高等級是SIL3
(美國INTEGRITY，加拿大QNX等)
實時操作系統(tǒng)的安全性問題。目前許多實
時操作系統(tǒng)采用了分區(qū)技術，該技術將不同的
軟件部分放在受保護的地址空間，因此程序某
個部分出錯或受侵害時不會影響到整個系統(tǒng)。
分區(qū)型內核架構是目前人們認可的設計軟件的
惟一正確方法。它可用在：需要保證CPU時間
和內存的許多應用場合；以簡單的方式安全連
接任何設備。
參考文獻：
Eli IEC． IEC 61508 Functional Safety of Electrica1／Electr0nic／
Programming Electronic Safety-Related Systems Part 0 Part 7
[s]．International Electrotechnical Commission，2010．
[2] IEC． IEC 61511 Functional Safety — Safety Instrumented
Systems for the Process Industry Sector[S]． International
Electrotechnical Commission，2003．
[3] GOBLE W M．控制系統(tǒng)的安全評估與可靠性[M]．白焰，譯．
2版．北京：中國電力出版社，2008．
E4] ZHAO Minda． Nuclear Safety—Critical Software v&amp;amp;v
Techn。logy[R]．AECL，2O10．
[5] HECHT M， BRII I R． Review Guideline for Software
W ritten in High Level Programm ing I anguages U sed in
Safety Systems[R／OL]．[2olo一12—20]． http：／／www．
sohar．com／proj——pub／download／wrsmpaper3a．pdf．
魏德米勒SAI外殼—— 全面的外殼解決方案的首選
魏德米勒為SAI產品研發(fā)了一款防護等級達IP67的模塊化高性能外殼，簡單安裝無需密封是其顯著特征，因此空置
SAI外殼特別適合按照客戶要求提供相應的定制服務。M12 PCB聯(lián)接件，可根據(jù)需要單獨定制外殼解決方案。所有聯(lián)接
件被設計為能夠承受高達105℃ 的工作溫度，空外殼的寬有兩種尺寸：54 mm和30 rnm，30 mm寬的系列有不同長度可選，
除了簡單的外殼裝配，回流焊簡化了兼容M12的印刷電路板聯(lián)接件，除了帶M12螺紋襯套的I／O蓋(2×4，可選屏蔽或非
屏蔽)，還提供2×8的M8螺紋襯套的I／O蓋。各自的I／O蓋有3個M12和1個M12或1個M8可用接口。30 mrfl寬系
列的空外殼也能夠安裝M12或M8連接器(1×4或1×8)。
魏德米勒電聯(lián)接國際貿易(上海)有限公司

網(wǎng)友評論 more

綜合安全論文最新內容

04-10