北京廣利核系統(tǒng)工程有限公司 吳彬,張源,趙勇
隨著越來越多的核電站使用數(shù)字化儀控系統(tǒng),數(shù)字化儀控系統(tǒng)對核電站安全的重要性也正在增加,系統(tǒng)需求在數(shù)字化儀控系統(tǒng)研發(fā)過程中的地位也越來越重要。需求收集階段在IEEE1213中規(guī)定的需求開發(fā)流程中的位置如圖1所示。
本文通過分析標準中對需求收集方法的介紹和核電數(shù)字化儀控平臺的特殊性,最終得出適合核電數(shù)字化儀控平臺的需求收集方法。
IEEE 1233-1996(IEEE Guide for Developing System Requirements Specifications)用于指導開發(fā)系統(tǒng)需求規(guī)格書,該標準中描述需求收集的來源如圖2所示。

圖1 需求開發(fā)流程

圖2 系統(tǒng)需求收集來源
標準中給出了一些需求收集方法的建議:
調查/問卷;
對手系統(tǒng)評定;
原型;
頭腦風暴會議或問題-方案會議;
仿真;
工作模式的觀察(e.g. 工業(yè)操作效率的研究分析);
會談;
逆向工程(從后期的工作產品導出作為其基礎的前期工作產品的過程);
研究系統(tǒng)的組織和政治環(huán)境(e.g., 社會關系圖)。
由于標準中更多注重的是系統(tǒng)需求,如果單純按照標準中的方法進行需求收集,開發(fā)人員會面臨無法將收集到的系統(tǒng)需求轉化為自己熟悉的平臺需求,所以標準中的需求收集方法僅作為參考,需求開發(fā)人員應找出一種適合自己的平臺需求收集方法,但在需求收集階段應遵照標準中提到的需求來源。
由于核電數(shù)字化儀控平臺的特殊性,需求收集的對象應關注:
核電相關法規(guī)標準(IEEE、IEC、GB、HAD、HAF……);
核電廠設計準則(單一故障、共因故障、多樣性……);
核電廠可靠性指標(拒動率、誤動率、MTBF……)。
數(shù)字化儀控平臺,是指一系列硬件產品、軟件產品和輔助工具的組合,由這些產品所集成的系統(tǒng),應具備DCS的基本功能特征,如信號調理、信號采集與輸出、數(shù)據(jù)通信、運算處理、信息控制與顯示、系統(tǒng)接口和組態(tài)工具等,它還應具有可升級性和可擴展性的特征。數(shù)字化儀控平臺需求是平臺研發(fā)人員可以直接用于開發(fā)平臺的需求,對于平臺研發(fā)人員來說,合適的需求收集方法不需要逐步分析如何從系統(tǒng)需求轉化為平臺需求,能夠提高工作效率,降低最后開發(fā)出來的產品不滿足客戶要求的風險。
針對標準中對需求收集的要求及核電數(shù)字化儀控平臺的要求,需求收集方法的使用應該是一個相互結合而又反復進行的過程,每種方法進行完之后都要對收集的需求做記錄,并交由各方審查核實,以保證需求信息的可靠和準確。我們選取了兩種適用于數(shù)字化儀控平臺開發(fā)的需求收集方法。
在收集需求之前,需求開發(fā)人員經常感覺收集對象不清晰,不知道從哪些方面去收集需求,最終導致收集到的需求龐大而無用。在需求開發(fā)流程中增加概念分析階段可極大的減少這種情況的發(fā)生。
增加概念分析階段的目的是根據(jù)核電廠中應用系統(tǒng)、公司或部門的規(guī)劃文件,確定平臺的設計基礎框架;提前解決在需求開發(fā)中會遇到的矛盾的、有沖突的、不確定的問題,使項目的管理人員、技術人員、用戶在后續(xù)的需求開發(fā)理解上保持一致;提前分析并評估在平臺系統(tǒng)設計中可能會遇到的關鍵問題,降低開發(fā)過程中的風險,為后續(xù)的需求開發(fā)過程提供輸入。
概念分析階段應注意以下幾個方面。
4.1.1 確定目標應用范圍
概念分析階段的首要任務是確定平臺開發(fā)的目標應用范圍,如應用于保護系統(tǒng)、控制系統(tǒng)或某類專用系統(tǒng)等。
需求開發(fā)人員應根據(jù)來自用戶或設計院的目標應用系統(tǒng)需求文件及相關設計文件,公司或部門發(fā)布的平臺可行性報告、立項報告或平臺規(guī)劃等文件,初步確定目標應用范圍。在初步確定目標應用范圍后,結合系統(tǒng)設計人員、平臺開發(fā)人員和其他相關技術人員的開發(fā)、設計經驗,對目標應用范圍進一步討論,形成一致意見并最終確定目標應用范圍。
4.1.2 確定認證要求
需求開發(fā)人員應確定平臺產品將來可能需要的認證要求,如核安全級鑒定、功能安全認證等。
4.1.3 確定平臺架構
需求開發(fā)人員應在概念分析階段確定平臺架構,劃分平臺子功能模塊,并描述各子功能模塊的相應功能。
架構圖應包含如下內容:
平臺產品的范圍;
平臺與外部系統(tǒng)的接口關系;
平臺中的網(wǎng)絡拓撲結構;
平臺中的功能單元,以及各單元之間的關系;
控制站內部功能單元;
對各種功能單元的目標功能進行詳細描述;
對各種網(wǎng)絡拓撲和傳輸方式進行描述;

圖3 平臺系統(tǒng)架構圖
4.1.4 關鍵技術點分析
在概念分析階段,需求開發(fā)人員應對關鍵技術進行分析,包括如下內容:
對接口關系及接口信號進行描述;架構圖示意圖如圖3所示。
識別出應用系統(tǒng)對平臺的重要約束;
識別出平臺設計中可能遇到的難點和關鍵技術點;
分析以上問題,提出解決問題的幾種方案并確定解決方法。
確定了平臺的范圍之后,需求開發(fā)人員可以使用事件驅動法將平臺要完成的事情劃分為相互獨立的用例,以分析平臺必須具備的要求。事件驅動法通過發(fā)現(xiàn)平臺所要響應的業(yè)務事件來確定平臺要完成的事情,即平臺的功能需求。如果平臺的范圍太大,難以作為一個整體進行研究,則可以把平臺分解為一些獨立的單元,通過研究分解的單元以發(fā)現(xiàn)平臺系統(tǒng)需求。
使用事件驅動法收集需求的步驟如下:
4.2.1 識別事件
業(yè)務事件有兩種觸發(fā)方式:
(1)事件觸發(fā)方式,例如下列事件:
現(xiàn)場傳感器信號輸入;
一定條件下(如現(xiàn)場傳感器信號超閾值)向控制現(xiàn)場設備輸出信號;
現(xiàn)場傳感器信號的網(wǎng)絡輸出;
顯示設備的控制信號輸入;
網(wǎng)絡輸入數(shù)據(jù)的邏輯符合輸出;
工程師站邏輯組態(tài)下裝。
(2)時間觸發(fā)方式,如下列事件:
平臺自監(jiān)視和自診斷信息顯示。
4.2.2 確定平臺用例
平臺的功能是對事件響應的一系列處理過程,處理過程一直持續(xù)到要滿足的事件全部完成(例如:信息被顯示、控制被輸出、數(shù)據(jù)被存儲等)。如圖4所示。

圖4 事件驅動法用例圖
由平臺完成的響應就是一個用例,每個用例都是平臺功能的一部分。通過研究事件以及平臺如何響應外界的事件來發(fā)現(xiàn)用例。
4.2.3 發(fā)現(xiàn)需求
(1)功能性需求
通過事件用例分析功能性需求,把完成這個用例所需要的步驟列舉出來,作為發(fā)現(xiàn)用例功能性需求的一種方法。
例如對于信號采集,用例步驟描述建議列舉為:
信號從傳感器輸入,平臺需實現(xiàn)與傳感器信號的電氣隔離;
對于隔離后的信號,平臺需要分配為n路信號;
對信號進行量程比較,判斷信號“好、壞”;
將信號轉換為標準的電氣信號,并采集為數(shù)字化信號進入平臺處理。
可以得到以下用例圖,如圖5所示。
(2)非功能性需求
非功能性需求是產品必須具備的屬性或品質。一旦知道了平臺需要完成的事情,就可以確定它的行為方式,它需要具備什么品質,如它應該多大或者多快。非功能性需求通過其他需求收集

圖5 功能性需求用例圖

圖6 非功能性需求用例圖
目前這兩種需求收集方法已經在北京廣利核系統(tǒng)工程有限公司的數(shù)字化核安全級控制保護系統(tǒng)(FirmSys)平臺和基于現(xiàn)場可編程門陣列FPGA技術的數(shù)字化儀控系統(tǒng)平臺(FitRel)成功使用。對于平臺開發(fā)人員來說,使用這兩種需求收集方法能更好的便于他們理解平臺將要應用的環(huán)境,對原始需求轉換為平臺需求提供了良好的過渡。
[1]IEEE 1233-1996,IEEE Guide for Developing System Requirements Specifications[S].
[2]IEEE 830-1998,Recommended Practice for Software Requirements Specifications[S].
[3](英)羅伯遜(Robertson,S.),掌握需求過程(第2版)[M].北京:人民郵電出版社, 2007.
[4]毋國慶. 軟件需求工程[M]. 機械工業(yè)出版社2010,8.