鮑 陽 楊志斌 楊永強 謝 健 周 勇 岳 濤 黃志球 郭 鵬

1(南京航空航天大學計算機科學與技術學院 南京 211106)2(高安全系統(tǒng)的軟件開發(fā)與驗證技術工信部重點實驗室(南京航空航天大學) 南京 211106)3(航空工業(yè)計算所 西安 710065)

安全關鍵信息物理融合系統(tǒng)[1-3](safety-critical cyber-physical system, SC-CPS)是指廣泛應用于航空、航天、交通、能源等領域，且失效時會產生嚴重系統(tǒng)風險，從而導致財產損失、環(huán)境破壞或者人員傷害的一類CPS系統(tǒng).安全關鍵信息物理融合系統(tǒng)不僅集成了計算、網(wǎng)絡和物理環(huán)境，還同時具有高可靠性、高安全性、強實時性等特點.隨著功能、非功能需求的不斷增加，系統(tǒng)規(guī)模和復雜性不斷提高，這類系統(tǒng)出現(xiàn)故障的可能性及其造成的危害也日益突出.

近年來，模型驅動開發(fā)(model-driven development, MDD)越來越受到重視，并被工業(yè)界認為是保障系統(tǒng)安全性與可靠性切實可行的重要手段.模型驅動開發(fā)方法[4]將模型作為系統(tǒng)工程生命周期的中心，在設計階段建立系統(tǒng)的抽象模型，盡早對系統(tǒng)進行分析和驗證，并且支持不同層級模型之間信息的傳遞和映射.

安全關鍵系統(tǒng)領域常用的建模語言有UML,SysML,AADL等.統(tǒng)一建模語言(unified modeling language, UML)[5]是一種針對軟件工程領域的標準化建模語言，側重于軟件的體系結構建模，但是UML還不足以表達系統(tǒng)工程領域中的所有概念.體系結構分析和設計語言(architecture analysis & design language, AADL)[6]是一種面向安全關鍵嵌入式系統(tǒng)的建模語言，側重于軟硬件混合建模[7-8].系統(tǒng)建模語言(systems modeling language, SysML)[9]是一種針對系統(tǒng)工程領域的圖形化建模語言，是對UML2.0子集的擴展，側重于復雜系統(tǒng)的整體架構.相比UML,AADL等語言，SysML可以整合大型復雜系統(tǒng)的各種視圖，包括硬件、軟件、數(shù)據(jù)、過程、需求，甚至包括人力和其他資源，適用于進行需求捕獲、分析和初步系統(tǒng)設計，目前在工業(yè)界得到了廣泛應用.因此，本文選擇SysML作為系統(tǒng)架構建模語言.

模型驅動開發(fā)方法的生命周期通常始于系統(tǒng)的分析或設計階段，較少涉及需求階段.但是，安全關鍵信息物理融合系統(tǒng)中導致嚴重事故問題鏈的最上端原因往往是系統(tǒng)需求問題[10]，而這類系統(tǒng)的需求常常又是通過自然語言描述的.因此，如何有效鏈接自然語言需求和模型驅動開發(fā)方法，即實現(xiàn)自然語言需求到系統(tǒng)設計模型的自動或半自動轉換是模型驅動開發(fā)方法在安全關鍵信息物理融合系統(tǒng)設計與開發(fā)過程中面臨的一個主要挑戰(zhàn)[11-13].

已有的需求表達到系統(tǒng)設計模型的轉換主要包括基于自然語言處理(natural language processing, NLP)、基于限定自然語言(restricted natural language, RNL)模板[11,14]等方法.在自然語言處理方法方面，Bajwa等人[15]基于自然語言處理方法提出從自然語言需求到UML類圖中的OCL(object constraint language)文本說明的轉換.而Letsholo等人[16]提出的TRAM(tool for tranforming textual requirements into analysis models)方法，主要考慮自然語言需求到UML類圖的轉換.在限定自然語言模板方法方面，岳濤等人[17]提出的限定用例建模方法(restricted use case modeling, RUCM)方法是通過對UML用例圖的文本說明進行自然語言限定，以此降低自然語言帶來的二義性與模糊性，基于RUCM給出的aToucan工具[18]支持RUCM到UML活動圖、順序圖等的自動化生成；RollsRoyce公司提出的EARS[19](easy approach to requirements syntax)方法，通過一些簡單的需求結構來捕獲和表達用戶需求，從而降低自然語言需求的二義性.王政等人提出的SPARDL語言[20]，通過數(shù)據(jù)字典、模塊和模式圖對航天軟件需求進行捕獲.正在制定中的SysML V2.0標準[21]也將通過預定義關鍵字和句式對需求圖的自然語言描述作出限定，從而減少SysML建模過程中由自然語言帶來的不精確性等問題.另外，Colombo等人[22]提出基于問題框架(problem frames)的需求分析并將需求規(guī)約轉換到SysML的方法，該研究主要考慮基于問題分解的方式獲得系統(tǒng)初始層次架構，還未考慮系統(tǒng)非功能等特性.

本文結合自然語言處理和限定自然語言模板兩者的優(yōu)點，面向安全關鍵信息物理融合系統(tǒng)，提出一種基于限定中文自然語言需求的SysML模型自動生成方法.為了盡量不改變國內系統(tǒng)工程師基于文檔撰寫需求的習慣，我們提出限定中文自然語言需求模板(restricted natural language requirement, RNLReq)，這樣使得自然語言需求表達不受限于SysML需求圖.另外，從需求到設計模型的建立，目前大多數(shù)情況下是手動實現(xiàn)的，整個過程對于建模人員有著很高的要求，需要掌握來自多個學科的領域知識，所以給出限定自然語言需求到SysML設計模型的自動轉換.本文所使用的SysML設計模型主要包括結構視圖(即塊定義圖)、通信視圖(即內部塊圖)、行為視圖(即活動圖)及非功能屬性擴展等.

文獻[23-24]中給出了基于限定中文自然語言需求的AADL模型自動生成方法.本文正是在現(xiàn)有研究的基礎上，進一步考慮基于限定中文自然語言需求的安全關鍵信息物理融合系統(tǒng)SysML建模，并通過基于人工智能的安全關鍵信息物理融合系統(tǒng)術語提取和推薦方法，對系統(tǒng)需求中的領域術語和數(shù)據(jù)字典加以自動提取，提高限定自然語言需求規(guī)約工作的自動化程度.

相比已有工作，本文主要貢獻有3個方面：

1) 提出一種結合智能化推薦的限定中文自然語言需求規(guī)約方法.為了減少中文自然語言需求表達中存在的模糊性、二義性，提出基于限定中文自然語言需求模板的需求規(guī)約方法.該方法包括領域詞庫、數(shù)據(jù)字典和限定自然語言模板.結構化的限定自然語言模板，對系統(tǒng)靜態(tài)結構、內部交互、動態(tài)行為以及非功能約束在內的系統(tǒng)需求的各方面進行規(guī)約.為了增強需求規(guī)約方法的自動化程度，通過智能化推薦的方法，將系統(tǒng)需求文檔中的術語加以提取并推薦到領域詞庫和數(shù)據(jù)字典中.

2) SysML設計模型的自動生成方法.針對SysML對安全關鍵信息物理融合系統(tǒng)的安全性、可靠性、實時性等非功能需求表達能力的不足，提出SysML擴展子集，使其具有對非功能屬性描述的能力，并給出RNLReq到SysML子集的轉換規(guī)則與算法.

3) 原型工具實現(xiàn)和工業(yè)界案例分析.基于開源工具Papyrus對本文方法進行原型工具實現(xiàn)，并以航空領域的飛機空氣增壓系統(tǒng)(airplane air com-pressor system)作為案例，對所提方法的可用性和有效性進行驗證.

1 研究背景

本節(jié)主要介紹SysML的基本建模概念及自然語言處理技術.

1.1 SysML概述

國際系統(tǒng)工程學會(International Council on Systems Engineering, INCOSE)和對象管理組織(Object Management Group, OMG)在對UML2.0的子集進行重用和擴展的基礎上，于2006年提出系統(tǒng)建模語言SysML.SysML是針對系統(tǒng)工程領域的標準建模語言，可以構建設計良好、層次清晰且可維護的復雜系統(tǒng).SysML不僅可以整合大型復雜系統(tǒng)的各種視圖，除了包括硬件和軟件，還包括數(shù)據(jù)、過程、需求，甚至包括人力和其他資源，還可以描述系統(tǒng)的層次、結構、行為、屬性及組件間的復雜關系.SysML能夠支持各種大型復雜系統(tǒng)的詳細說明、分析、設計、驗證和確認，適合于進行需求捕獲、分析和初步系統(tǒng)設計，目前在主要的工業(yè)領域如航空、航天、交通、能源等領域得到了較為廣泛的應用.

SysML中定義了3種類別共9種圖來刻畫系統(tǒng)在不同視角下的特征.1)描述需求的視圖：需求圖(requirement diagram, REQ)提供基于文本需求的建模構件，用于描述自然語言需求、需求之間的關系，以及需求與其他模型元素之間的關系.2)描述結構的視圖：模塊定義圖(block definition diagram, BDD)表示系統(tǒng)之間的組成關系；內部模塊圖(internal block diagram, IBD)用于描述系統(tǒng)的內部架構及抽象通信；參數(shù)圖(parametric diagram, PAR)用于描述系統(tǒng)的屬性信息的約束條件，表示一種或多種約束如何與系統(tǒng)的屬性綁定；包圖用于顯示系統(tǒng)模型的組織方式.3)描述行為的視圖：用例圖(use case diagram, UC)從系統(tǒng)參與者的角度表達系統(tǒng)執(zhí)行的用例，是一種黑盒視圖；活動圖(activity diagram, ACT)主要關注控制流程，以及輸入通過一系列動作轉換為輸出的過程；序列圖(sequence diagram, SD)主要關注模塊的組成部分如何通過操作調用和異步信號交互；狀態(tài)機圖(state machine diagram, SMD)主要關注模塊的一系列狀態(tài)，以及響應事件時狀態(tài)之間的轉換.對于特定領域系統(tǒng)建模，SysML允許用戶通過擴展機制對元模型進行擴展和調整，獲得原始模型不具備的描述信息存儲、非功能需求以及分析的能力.本文主要采用構造型(stereotypes)的方式擴展SysML，包括2種方式:1)擴展(extension) UML的元類;2)繼承(generali-zation) SysML已有的構造型.

1.2 自然語言處理

自然語言處理(NLP)是指在機器語言和人類語言之間進行“翻譯”，以實現(xiàn)人機交流的目的.自然語言處理的關鍵技術包括自動分詞、詞性標注、命名實體識別、句法分析、語義分析與篇章分析等.本節(jié)主要描述分詞、詞性標注以及依存句法分析.

1) 分詞

分詞(tokenization)就是將句子、段落、文章這種長文本，分解成以詞語為單位的數(shù)據(jù)結構，方便后續(xù)的處理分析工作.同一個長詞語，通常有不同分法，例如“飛行器管理計算機”，可以有“飛行器管理計算機”“飛行器管理計算機”“飛行器管理計算機”3種分法.

2) 詞性標注

詞性標注(part of speech tags, POS tags)就是在給定句子中判定每個詞語的語法范疇，確定其詞性并加以標注的過程.本文中使用到的主要詞性如表1所示.

Fig. 1 The framework of the automated approach to generate SysML models from natural language requirements圖1 基于自然語言需求的SysML模型自動生成方法整體框架

3) 句法分析

句法分析(syntactic parsing)是對輸入的文本句子進行分析以得到句子的句法結構的處理過程.根據(jù)句法結構的表示形式不同，可以分為3種：①句法結構分析(syntactic structure parsing)，作用是識別出句子中的短語結構以及短語之間的層次句法關系；②依存句法分析(dependency syntactic parsing)，作用是識別句子中詞匯與詞匯之間的相互依存關系；③深層文法句法分析，即利用深層文法對句子進行深層的句法以及語義分析.依存句法理論認為“謂語”中的動詞是一個句子的中心，其他成分與動詞直接或間接地產生聯(lián)系.它將句子分析成一顆依存句法樹，描述出各個詞語之間的依存關系.一個依存關系連接2個詞，分別是核心詞(Head)和依存詞(Dependent).依存關系可以細分為不同的類型，包括定中關系ATT、數(shù)量關系QUN(quantity)、動賓關系VOB(verb-object)、主謂關系SBV(subject-verb)等.

Table 1 Meanings and Examples of Common POS Tags表1 常用詞性的含義和舉例

2 研究框架

本文面向安全關鍵信息物理融合系統(tǒng)，針對中文自然語言需求與模型驅動開發(fā)方法之間的鴻溝展開研究，提出了一種基于限定中文自然語言需求模板的系統(tǒng)需求規(guī)約方法，并通過基于人工智能的術語提取方法對需求規(guī)約方法中的領域術語和數(shù)據(jù)字典加以推薦；然后，通過轉換規(guī)則和轉換算法自動生成SysML系統(tǒng)設計模型.本文的研究框架如圖1所示，主要分為3個部分：

1) 為了確保需求表達的一致性，采用領域詞庫和數(shù)據(jù)字典，實現(xiàn)對需求文檔中的數(shù)據(jù)、對象名詞的集中管理和規(guī)范描述.使用自然語言處理技術對系統(tǒng)需求文檔進行分析，依據(jù)領域特征、專家意見、工程需求和文獻調查等制定提取規(guī)則，完成領域詞庫和數(shù)據(jù)字典的推薦與制定.

2) 在數(shù)據(jù)字典和領域詞庫的基礎上，按照設定的限定自然語言需求模板完成具體的系統(tǒng)需求規(guī)約，在此過程中，為了減少自然語言的二義性，對自然語言的表達方式進行適當限制，即遵循一定的限定規(guī)則給出對系統(tǒng)需求的描述.

3) 為了增強SysML對安全關鍵信息物理融合系統(tǒng)的安全性、可靠性、實時性需求的表達能力，提出SysML擴展子集.在通過限定自然語言需求模板完成整個系統(tǒng)需求規(guī)約后，根據(jù)限定自然語言需求模板到SysML和擴展的生成規(guī)則以及具體的轉換算法，生成SysML系統(tǒng)設計模型.

3 基于限定中文自然語言模板的需求規(guī)約方法

限定自然語言需求規(guī)約方法主要由領域詞庫、數(shù)據(jù)字典以及需求模板3部分組成.

3.1 領域詞庫與數(shù)據(jù)字典

對象名詞、數(shù)據(jù)及其屬性等通常散布在需求文檔各處，不利于保證同一個概念的一致表達.領域詞庫和數(shù)據(jù)字典可以分別對對象名詞和數(shù)據(jù)進行集中管理和規(guī)范描述，方便后續(xù)的需求建模過程.

1) 領域詞庫

領域詞庫(glossary repository)是指涵蓋需求文檔中的各種對象名詞的詞庫.領域詞庫中需要填寫對象名詞的中文名、英文名、名詞類別、ID等信息.圖2給出了領域詞庫的BNF語法.針對安全關鍵信息物理融合系統(tǒng)領域的實際需求，領域詞庫可以包括專有的系統(tǒng)名、功能名、組件名、接口名、硬件設備名、模式名、狀態(tài)名等.通過在領域詞庫中注冊使用的詞匯，實現(xiàn)對需求文檔編寫的限定，以減少在需求編寫過程中出現(xiàn)人為錯誤的可能.

Fig. 2 BNF grammar of glossary repository圖2 領域詞庫的BNF語法

2) 數(shù)據(jù)字典

數(shù)據(jù)字典(data dictionary)是指涵蓋需求文檔中涉及的數(shù)據(jù)及其屬性的字典.數(shù)據(jù)字典中需要填寫數(shù)據(jù)的中文名、英文名、數(shù)據(jù)組成(例如，(角速度，角位置))、單位、范圍、精度、速率、ID等信息.圖3給出了數(shù)據(jù)字典的BNF語法：

Fig. 3 BNF grammar of data dictionary圖3 數(shù)據(jù)字典的 BNF 語法

針對領域的實際需求，數(shù)據(jù)字典中可以包括靜態(tài)數(shù)據(jù)、輸入數(shù)據(jù)、輸出數(shù)據(jù)等[23].其中，靜態(tài)數(shù)據(jù)是指系統(tǒng)中的常數(shù)、預先裝訂的參數(shù)；輸入、輸出數(shù)據(jù)是指系統(tǒng)在運行過程中各組件的輸入、輸出數(shù)據(jù).此外，針對安全關鍵信息物理融合系統(tǒng)對安全性、可靠性的要求，可以添加對故障概念進行描述的數(shù)據(jù)，如故障等級、故障類型、失效影響、失效概率等；針對SC-CPS結合連續(xù)和離散動態(tài)特征的特性，在數(shù)據(jù)字典中通過數(shù)據(jù)的速率特征以統(tǒng)一表達，速率取值為數(shù)值或者分布，當速率取值為0時表示連續(xù)的數(shù)據(jù)流，速率為非0時表示離散的數(shù)據(jù)流，速率取值為分布時表示不確定時間間隔發(fā)射的數(shù)據(jù).對于常見的固定取值，例如分布、故障等級等，可以預先定義為靜態(tài)數(shù)據(jù)，范圍為枚舉值：1)(distribution)，如(Normal(mean,stdDev),Uniform,Basic(min,max));2)(failure level)，如(NoEffect,Minor,Major,Hazard).

例如，“輸入功能每隔15 ms將旋轉變壓器采集數(shù)據(jù)發(fā)送到控制功能，旋轉變壓器采集數(shù)據(jù)包括角速度和角位置數(shù)據(jù)”，在數(shù)據(jù)字典中注冊該數(shù)據(jù)的中英文名(旋轉變壓機采集數(shù)據(jù)Rotary_transformer_gathered_data)、數(shù)據(jù)類型組成(例如(角速度，角位置))、單位、范圍、精度、頻率(10 ms)、ID等信息，作為對該數(shù)據(jù)的解析.需要注意的是，這里的角速度和角位置不是基本數(shù)據(jù)類型，因此也需要注冊到數(shù)據(jù)字典中.

3.2 基于自然語言處理的術語推薦方法

本節(jié)我們主要介紹基于自然語言處理技術提出面向安全關鍵信息物理融合系統(tǒng)的術語推薦方法，這里的術語包括領域詞庫和數(shù)據(jù)字典.術語推薦方法的NLP過程主要包括分詞、詞性標注、依存句法分析、規(guī)則提取、領域度過濾等步驟，如圖4所示:

Fig. 4 Framework of glossary extraction圖4 術語提取技術框架

詳細介紹各個步驟:

1) 分詞、詞性標注、依存句法分析

例如，對于“飛機管理計算機通過遠程接口單元，發(fā)送啟動空壓機的指令給空氣增壓機控制器”需求語句，進行分詞、詞性標注、依存句法分析，處理結果如圖5所示.本文中選取的文本分析工具為HanLP自然語言分析工具包，由一系列模型與算法組成，因此本步驟直接使用HanLP來實現(xiàn).

Fig. 5 Results of POS tagging and parsing圖5 詞性標注和句法分析的結果

2) 規(guī)則提取

安全關鍵信息物理融合系統(tǒng)領域術語存在語言結構特征.從外部關聯(lián)來看，領域術語大多是名詞性短語，其經常作為領域文本中的主語、賓語、定語等成分；從其內部語法構成來看，其組成形式包括名詞+名詞(“空氣壓縮機控制器”)、形容詞+名詞(“可信數(shù)據(jù)”)、動詞+名詞(“自檢功能”)、動詞(名詞)+單字名詞(“電磁閥”)等.

根據(jù)語言結構特征、專家意見和文獻調查，結合詞性標注和依存分析的結果，制定詞語匹配規(guī)則，如表2所示.例如“飛機管理計算機發(fā)送啟動空氣增壓機的指令”需求中符合匹配規(guī)則的候選術語有5個:“飛機”“飛機管理”“飛機管理計算機”“管理計算機”“計算機”，依據(jù)R1規(guī)則可以提取名詞短語“飛機管理計算機”“空氣增壓機”.依據(jù)R2規(guī)則可以提取單獨出現(xiàn)的名詞“指令”.

Table 2 Pattern Matching Rules表2 匹配規(guī)則

3) 領域度過濾

安全關鍵信息物理融合系統(tǒng)領域術語還存在特定領域特征，即該術語通常僅出現(xiàn)在一些特定領域的文本中.領域度過濾對存在常用詞語和停用詞的候選術語進行過濾.候選術語中“計算機”和“發(fā)送啟動”為不存在領域特征的常用詞語，因此被過濾.

經過以上步驟后，將候選詞推薦給系統(tǒng)工程師進行人工分析篩選，用于后續(xù)的需求建模，可以有效提高建模工作的自動化程度.

3.3 限定中文自然語言需求模板

隨著安全關鍵信息物理融合系統(tǒng)越來越復雜，系統(tǒng)中包含更多的來自不同領域的物理子系統(tǒng)、計算子系統(tǒng)、通信子系統(tǒng).這類系統(tǒng)往往采用分布式構件設計，將一個完整的系統(tǒng)看成若干獨立的子系統(tǒng)，每個獨立的子系統(tǒng)封裝為標準化的構件，對這些標準化構件的組合可以開發(fā)出具備特定功能的系統(tǒng).我們正是基于系統(tǒng)分解結構來組織需求模板的結構.

在基于構件的系統(tǒng)中，系統(tǒng)的體系結構可以層次分解為系統(tǒng)、子系統(tǒng)、功能以及共享功能.對應的，需求模板之間的層次關系則顯式地表達系統(tǒng)的體系結構.其中，系統(tǒng)(system)需求模板可以細分為多個子系統(tǒng)(subsystem)需求模板，按照自頂向下分解的方法，子系統(tǒng)可以繼續(xù)劃分為多個子系統(tǒng)、功能(function)或共享功能(shared function)模塊.

功能需求模板是只能被所屬系統(tǒng)調用的功能.此外，共享功能模塊作為獨立的模塊掛靠在系統(tǒng)中，可以被其他系統(tǒng)或功能調用，用于描述一些經常被調用到的算法(如傅里葉變換、矩陣變換、歐拉角計算)或與外設交互(如從總線讀寫數(shù)據(jù)).在進行自然語言需求模板設計時，除了考慮系統(tǒng)構件化特征之外，還可以在需求模板中添加部分必要的設計相關元素，用于支持后期設計模型的自動化生成.

系統(tǒng)、子系統(tǒng)、功能以及共享功能均需遵循如表3所示的基本模板.對于每個系統(tǒng)或子系統(tǒng)而言，都有相應的輸入輸出信號(signal)，包括數(shù)據(jù)(data)和事件(event)兩種類型，同時每個(子)系統(tǒng)還需對其功能需求(functional requirement)、性能需求(performance requirement)、安全性需求(safety requirement)、可靠性需求(reliability requirement)進行描述.而功能需求、性能需求、安全性需求、可靠性需求還要遵循各自的模板.此外，每個(子)系統(tǒng)都有對應的原始需求ID，用于記錄對應的原始文本需求.下面給出具體的自然語言限定規(guī)則.

Table 3 Restricted Natural Language Requirement Template表3 限定自然語言需求模板

1) 通用約束規(guī)則

由于自然語言表達存在著二義性，在填寫需求模板時會造成歧義，針對不同類型的需求，本文規(guī)定了一系列通用的自然語言約束規(guī)則來約束需求描述的填寫，如表4所示.

我們進一步以功能、性能、安全性、可靠性等需求為例對限定自然語言約束規(guī)則進行細化說明.

2) 功能需求約束規(guī)則

功能需求是指系統(tǒng)在功能層面上的需求描述，即事件、觸發(fā)條件、不變量等之間的關系，還包括多個事件序列、多個條件序列等復雜執(zhí)行的情況.對于安全關鍵信息物理融合系統(tǒng)而言，功能執(zhí)行主要包括順序執(zhí)行、選擇執(zhí)行、循環(huán)執(zhí)行等控制結構，而每個控制結構由若干個簡單行為句式組成.針對系統(tǒng)的功能特征，制定了5種簡單行為句式：發(fā)送(數(shù)據(jù)、信號)、賦值(數(shù)據(jù))、調用(功能)、延時、跳轉，調用語句可以描述不同模塊之間的功能交互關系.具體的簡單行為句式說明如表5所示.

Table 4 General Restriction Rules for Natural Language表4 通用自然語言約束規(guī)則

Table 5 Simple Behavior Sentences for Restricted Natural Language表5 限定自然語言簡單行為句式

上述的簡單行為句式只能表示基本的功能行為，不能適用于系統(tǒng)需求中的一些復雜的事件序列、條件序列等執(zhí)行行為，因此需要通過預定義的關鍵字(IF ELSE,AND,OR,LOOP等)和句式將簡單的描述語句組合成復合行為句式(compound sentence).表6給出限定自然語言復合控制結構的基本定義.這里以一條實際需求語句解釋我們的規(guī)約思路.例如，需求語句“若加電設備運行超過2 h，那么系統(tǒng)應該每隔15 min發(fā)出一次自檢信號直到加電結束”，首先需要在領域詞庫中添加表示“加電結束狀態(tài)”的詞條，在數(shù)據(jù)字典中定義“加電設備運行時間”數(shù)據(jù)，其數(shù)據(jù)組成類型為int，單位為h；應用S2，R14，R15三條約束規(guī)則，可將該需求重寫到需求模板：“[IFPower-UP-Device-Run-Time≥2 h,[Loop[Send:BIT-SignaltoBIT-Port]EACH 15 min UNTILPOWERUP-STOPPED]]”，這里的Send行為為當前需求中包含的最小行為單元.如果這里在發(fā)送自檢信號的同時需要進行計數(shù)，則可以應用R16的并行語句MEANWHILE[Send:BIT-SignaltoBIT-Port,Call:CountFunction]來替換原來Loop語句中的Send行為.

Table 6 Compound Structures for Restricted Natural Language表6 限定自然語言復合控制結構

Fig. 6 Structure of the functional requirement template圖6 功能需求模板結構

通過多層復合結構的組合，限定自然語言需求模板可以表達復雜的行為模式.圖6給出功能需求模板的結構示意圖.從模板結構中我們可以看出，整個功能需求模板是一個復合行為，可以根據(jù)實際需求填寫其中的空位，而它的系統(tǒng)行為的空位，可以填寫的模板類型既可以是多個簡單行為，也可以是層層嵌套的復合行為，使得功能需求模板具有良好的魯棒性和可擴展性，能夠表達層次性很強的功能行為.對于復雜的功能，我們可以將其層次分解，把其中出現(xiàn)在多個地方的通用功能行為(如算法)抽取出來，在單獨的功能需求模板中定義它，然后只需要多次調用它.

3) 非功能需求約束規(guī)則

系統(tǒng)的功能需求定義了期望一個系統(tǒng)做什么，而非功能需求(non-functional requirements, NFRs)則制定了關于系統(tǒng)如何運行和功能如何展示的全局限制.這里需要注意，非功能需求并不是獨立于功能需求而存在的，非功能需求是對功能需求的補充.

非功能屬性包括安全性(safety)、可靠性(reli-ability)、性能(performance)、可維護性(maintain-ability)、可伸縮性(scalability)和可用性(availabi-lity)等，這些非功能屬性對于航空航天CPS而言尤為重要，因為它們在無法提供服務時會造成巨大損失.其中，能夠定量描述與分析的非功能屬性主要有性能、可靠性、安全性.系統(tǒng)的時間性能要求，即實時性要求，包括周期性非周期執(zhí)行、Deadline、Time-out、Jitter、響應時間、可調度性等.可靠性要求，包括系統(tǒng)的故障、失效的發(fā)生概率.系統(tǒng)的資源性能要求，包括對功耗、CPU、存儲、總線、網(wǎng)絡帶寬等資源消耗和對溫度、質量、壓力等物理環(huán)境的約束.系統(tǒng)的安全性要求，一方面采用定性描述的方式來表達系統(tǒng)的故障行為和故障處理，在安全關鍵信息物理融合系統(tǒng)領域常用的故障或失效概念包括輸入異常、設備故障、斷電故障、通信故障等；另一方面采用定量描述的方式描述失效影響等級等.

依據(jù)安全關鍵信息物理融合系統(tǒng)特征，提出適用于性能、可靠性等非功能需求模板，如表7所示，并通過將非功能需求模板集成到對應的系統(tǒng)功能模板中，使得系統(tǒng)工程師在設計階段就可以全面考慮功能設計和非功能設計.

規(guī)則R17適用于約束系統(tǒng)的靜態(tài)屬性.例如，需求語句“周期自檢功能的周期為2 ms”，應用規(guī)則R17可以表達，該需求語句可以重寫為：“Period=2 ms”并添加到周期自檢功能的性能需求中.而規(guī)則R18則復用自規(guī)則R15，用于約束系統(tǒng)的動態(tài)行為，對于周期性執(zhí)行的行為，該需求將添加到功能需求模板之中.安全性需求中的故障處理行為，與功能需求緊密相關，可以應用規(guī)則R14添加到功能需求中.

Table 7 Non-functional Requirement Sentences for Restricted Natural Language

3.4 限定自然語言需求模板元模型

基于3.3節(jié)的需求模板約束規(guī)則，給出對應的需求模板元模型RNLReqTemplate.如圖7所示，Model描述的整個模型的最頂層概念，一般是指最頂層系統(tǒng).System實質上描述的是子系統(tǒng)的概念，一般而言，最頂層系統(tǒng)可以劃分為若干功能相對獨立的子系統(tǒng)，子系統(tǒng)依據(jù)其復雜程度又可進一步作為系統(tǒng)，再次劃分子系統(tǒng)，依此迭代，可以進行多層子系統(tǒng)劃分.

此外，對于每個系統(tǒng)或子系統(tǒng)而言，都有相應的輸入、輸出信號(signal)，信號一般分為數(shù)據(jù)(data)類型和事件(event)類型，同時每個(子)系統(tǒng)還需對其功能需求、性能需求(Performance Req)、可靠性需求(Reliability Req)、安全性需求(Safety Req)進行描述.

Fig. 7 Meta model of the RNLReqTemplate圖7 RNLReqTemplate元模型

4 SysML設計模型自動生成方法

由于安全關鍵CPS由異構的物理、計算、通信等部分組成，本節(jié)采用面向多視圖的方法對安全關鍵信息物理融合系統(tǒng)進行建模.首先，給出本文所使用的SysML子集；其次，給出限定自然需求模板到SysML設計模型的轉換規(guī)則與轉換算法.

4.1 SysML子集

SysML子集包括：層次結構視圖、內部通信視圖、行為視圖、非功能屬性視圖，其元模型如圖8所示.

Fig. 8 Meta model of SysML圖8 SysML元模型

1) 層次結構視圖

層次結構視圖反映了CPS系統(tǒng)中軟硬件結合的各分系統(tǒng)結構與模塊.如圖8中黃色方框部分所示，我們使用塊定義圖(block definition diagram, BDD)和Block表示層次結構視圖.Block是BDD的核心元素，表示系統(tǒng)靜態(tài)結構建模的基本構件，Block之間通過Composite Association表示組成關系.Block中的屬性表示系統(tǒng)的靜態(tài)屬性.

2) 內部交互視圖

內部交互視圖作為對層次結構視圖的補充，反映了系統(tǒng)內部各組件之間的交互.如圖8中綠色方框部分所示，我們使用內部塊圖(internal block diagram, IBD),Block,Port和Property描述內部交互視圖.在IBD中系統(tǒng)作為宿主Block存在，以組成屬性方式存在的子系統(tǒng)通過輸入輸出接口Port相互連接.Port中的Flow Property部分用于表示當前端口中傳輸?shù)臄?shù)據(jù)類型及其傳輸方向(in,out或inout).如果是同層系統(tǒng)之間的數(shù)據(jù)交互，則表示為Flow Property之間通過Port相連.相鄰2層系統(tǒng)之間的數(shù)據(jù)交互表示為Flow Property的一端連接到IBD邊框上的Port.

3) 行為視圖

如圖8中的藍色方框所示，本文主要使用活動圖(Activity Diagram, ActD)來表達系統(tǒng)行為，而且可以表示復雜的控制邏輯.

活動圖主要由活動節(jié)點(ActivityNode)和活動邊(ActivityEdge)組成.活動節(jié)點表示具體的動作或者控制信息，其中SendSignalAction和AcceptEvent-Action表示發(fā)送、接收事件動作，Signal表示其中事件或者數(shù)據(jù)的流動.DecisionNode和MergeNode可用于表示選擇、循環(huán)等行為結構.CallBehaviorAction節(jié)點可以由Activity定義，執(zhí)行CallBehaviorAction時可以調用另一種行為，實現(xiàn)復雜功能行為的層次分解.活動分區(qū)(ActivityPartition)表示多個子系統(tǒng)之間的動態(tài)交互，實現(xiàn)結構到行為的分配.針對SC-CPS中連續(xù)與離散的行為特性，通過對Control-Flow添加Rate構造型以表達以一定速率發(fā)送的事件.如圖9所示，在空氣壓縮機系統(tǒng)案例中(詳見5.2節(jié))，自檢模塊接收到上電信號后，周期自檢和上電自檢這2個任務并行執(zhí)行，其中周期自檢信息每隔15 ms發(fā)送并處理直到收到下電的信號，而上電自檢信息只會處理一次.輸出模塊和地面設備這2個外部設備的功能被執(zhí)行，且地面設備下載數(shù)據(jù)的功能在對應的行為視圖中進行了細化描述.

4) 非功能屬性視圖

如圖8中的紅色方框所示.基于Constraint的擴展以對系統(tǒng)中定量描述的非功能屬性進行建模，Constraint可以通過形式化的OCL表達式表達系統(tǒng)需求中的約束.這種方式可以將約束描述直接應用到某類對象的任何實例上.圖10(a)展示了如何使用AbstractRequirement和constraint一起定義一個新的ConstraintRequirement約束需求構造型.因為ConstraintRequirement的元類是Constraint，又是AbstractRequirement的子類型，所以它能夠描述受約束的需求，并且ConstraintRequirement可以用于修飾Block，Activitynode，Signal等元素，將需求信息分配到這些元素中.圖9中描述了功能行為中包含的一條性能需求“上電時間不得超過10 ms”.圖10(b)給出了CPS系統(tǒng)中常見的溫度需求，溫度傳感器Sensor1受到一個ConstraintRequirement構造型的約束，該約束使用OCL語言表達了一個限制傳感器工作溫度在-55～120℃的性能需求.約束的數(shù)據(jù)類型為基本類型，或由數(shù)據(jù)字典中自定義數(shù)據(jù)類型轉換而來的自定義構造型.Block，Interface，Signal等元素與AbstractRequirement通過trace關系相連接，表明需求最終在圖上的某些設計元素中得到滿足.

Fig. 9 Example of behavior view圖9 行為視圖舉例

Fig. 10 Definition of the NFR extension and examples of performance requirement圖10 非功能屬性擴展定義及性能需求舉例

4.2 轉換規(guī)則

限定自然語言需求模板到SysML的轉換方法可以分為3個部分：需求結構到層次結構視圖和內部交互視圖的轉換、功能需求到行為視圖的轉換、非功能屬性需求到非功能屬性視圖的轉換.這里使用System，Subsystem，F(xiàn)unction類型的Component分別表示系統(tǒng)、子系統(tǒng)、功能需求.

1) 需求結構到層次結構視圖和內部交互視圖的轉換，具體的轉換規(guī)則為：

規(guī)則1.對System和Function類型的Component，生成同名的BDD圖以及Block，系統(tǒng)屬性轉換為Block的property，若屬性的數(shù)據(jù)類型為數(shù)據(jù)字典中的非基本數(shù)據(jù)類型，則生成對應構造型.

規(guī)則2.頂層System Component轉換為BDD中的頂層Block，子系統(tǒng)轉換為下層Block，上下層Block之間通過Composition Association連接.

規(guī)則3.對內部端口連接信息不為空的System Component，生成IBD和Block類型的實例.

規(guī)則4.Subsystem Component的Block，添加為上一步生成IBD中Block的Property，將端口連接轉換為Property之間的Port.

2) 功能需求到行為視圖的轉換,具體的轉換規(guī)則為：

SysML活動圖是對表示系統(tǒng)的Block的功能行為的建模，主要通過活動節(jié)點、活動之間的遷移來描述系統(tǒng)的行為.功能需求Functional Req的存儲形式為Component的CompoundBehavior，其中由SimpleFunction組成功能鏈，將鏈表中的每個SimpleFunction轉換為動作節(jié)點，并適當?shù)靥砑涌刂乒?jié)點.下面詳細介紹具體的轉換規(guī)則.

規(guī)則1.對Function類型的Component，生成同名的ACT圖以及Activity.將輸入輸出數(shù)據(jù)添加為ActivityParameterNode.

規(guī)則2.對Component的CompoundBehavior進行遍歷，得到SimpleBehavior組成的鏈表.

規(guī)則3.如果鏈表非空，則生成InitialNode和FinalNode.

規(guī)則4.對于條件判斷類型的Condition，轉換為DecisionNode類型的節(jié)點.如果有Else，則生成2條出邊ActivityEdge；如果沒有Else，則只生成一條出邊ActivityEdge.對DecisionNode，生成對應的MergeNode，兩者分別作為頭尾包裹住Condition后的Function.

規(guī)則5.對于MEANWHILE語句，生成ForkNode和JoinNode，兩者分別作為頭尾與MEANWHILE后的CompoundBehavior生成的節(jié)點鏈相連.

規(guī)則6.對于事件觸發(fā)類型的Condition，轉換為AcceptEventAction類型的活動節(jié)點，根據(jù)輸入事件生成InputPin添加為節(jié)點的屬性，該節(jié)點只有一條出邊ActivityEdge.

規(guī)則7.將Call類型的AtomFunction轉換為CallBehaviorAction類型的活動節(jié)點，該節(jié)點只有一條出邊ActivityEdge.如果存在與該AtomFunction同名的ACT圖以及Activity元素，則將同名的Activity元素設為節(jié)點的behavior.輸入和輸出生成為InputPin和OutputPin，添加為節(jié)點的屬性.

規(guī)則8.將Send類型的AtomFunction轉換為SendSignalAction類型的活動節(jié)點，該節(jié)點只有一條出邊ActivityEdge.

基于轉換規(guī)則，給出從RNLReqTemplate到活動圖轉換的基本算法，如算法1所示.

算法1.功能需求到活動圖的轉換算法.

輸入:RNLReqTemplate;

輸出:SysMLModel.ActD.

① for each ComponentcinRNLReqTemplatewhereType=SYSTEM and hasFunction do

② DiagramactD=newActDiagram(c.name);

③diag.initialNode=newInitalNode();

④diag.finalNode=newFinalNode();

⑤ for each Composite Functioncfincdo

⑥ Nodestart=newNode();

⑦ Nodeend=newNode();

⑧traverse(cf,start,end);

⑨ end for

⑩ end for

(func.condition);

traverse(func.ifFunction,

start,end);

traverse(func.elseFunction,

start,end);

traverse(func.ifFunction,

start,end);

3) 非功能屬性需求到非功能屬性視圖的轉換，具體的轉換規(guī)則為：

需求模板中的非功能需求包括對系統(tǒng)的屬性約束和對功能行為的約束，下面詳細介紹具體的轉換規(guī)則.

規(guī)則1.若類型為SYSTEM的Component組件中存在Performance Req,Safety Req,Reliability Req，在Block中生成該Req描述的Property屬性.

規(guī)則2.由Component組件中的Constraint-Sentence生成ConstraintRequirement元素，將值約束轉換為OCL表達式.

規(guī)則3.若非功能需求在System中，并將Con-straintRequirement分配到BDD圖中Component組件對應的Block上.

規(guī)則4.若非功能需求在System中，并將Con-straintRequirement分配到活動圖中Component組件對應的節(jié)點上.

5 工具實現(xiàn)與案例分析

首先介紹RNL2SysML原型工具的總體框架；其次介紹工業(yè)界案例飛機空氣增壓系統(tǒng)，使用限定自然語言需求模板對飛機空氣增壓系統(tǒng)建模；最后給出通過RNL2SysML工具生成的SysML初始系統(tǒng)模型.

5.1 RNL2SysML原型工具實現(xiàn)

原型工具是在集成Papyrus插件的Eclipse平臺上進行開發(fā).開源建模工具Papyrus為SysML提供了完整的建模支持和SysML所需的圖形編輯器.

RNL2SysML工具框架如圖11所示，主要包括術語推薦模塊Glossary Extractor、需求視圖模塊Req Viewer、需求模板RNL Req Tool、RNL2SysML轉換引擎、圖形布局生成模塊Layout Visualizer等.

需求視圖模塊Req Viewer基于MVC(model-view-controller)的設計思想，將用戶界面與數(shù)據(jù)模型和模型操作進行分離:1)提供了中文用戶界面，主要基于領域詞庫和數(shù)據(jù)字典中的中文名，以及將句式中的關鍵字轉為對應的中文描述，如R14句式中的IF-THEN-ELSE轉為“若-執(zhí)行-否則執(zhí)行”.2)遵循表4～7中的約束句式進行設計，通過在界面上向用戶提供選擇而不是填寫，以盡可能避免用戶填寫導致的描述不一致現(xiàn)象.

Fig. 11 Framework of prototype tool圖11 工具框架

RNL2SysML原型工具的主要功能代碼統(tǒng)計如表8所示:

Table 8 Statistics of Functions of the Prototype Tool表8 原型工具主要功能的代碼統(tǒng)計

Fig. 12 Logical architecture of AACS圖12 AACS的邏輯架構

5.2 案例分析

本文的實驗分析旨在回答3個研究問題：

問題1.本文提出的術語提取方法的精確度如何？問題1旨在探究本文提出的術語提取方法與通用的自動術語提取方法的比較結果.

問題2.本文生成的SysML模型質量如何？問題2在探究本文提出的模型生成方法生成的設計模型對系統(tǒng)需求的覆蓋率，以及與其他工具的轉換能力的比較結果.

問題3.本文提出的模型生成方法的實用性如何？問題3旨在調查本文方法的學習成本，以及在實際應用中與人工建模時間的對比.

我們通過航空工業(yè)界的飛機空氣增壓系統(tǒng)案例對問題1～3進行評估，受篇幅限制，這里只展示部分需求.

首先，我們對飛機空氣增壓系統(tǒng)案例進行介紹.飛機空氣增壓系統(tǒng)(airplane air compressor system, AACS)，是保障飛機正常運行的核心系統(tǒng)，它為飛機供氣增壓，最核心的部件是空氣增壓控制器，將機上的270 V高壓直流電源，采用無刷方式轉換成方波或正弦波交流電源，用于驅動電機運轉，從而帶動空壓機工作.如圖12所示為AACS的邏輯架構，AACS主要功能包括初始化功能、供電功能、控制功能、自檢功能、模式管理功能、故障處理功能、存儲功能、輸入功能和輸出功能，下面分別介紹.

1) 初始化功能，對電路進行初始化和軟件的全局變量進行初始化.

2) 供電功能是機上電源對供電功能提供正常機上的270 V電源.

3) 控制功能主要控制電機、電磁閥和加熱器，將三者的控制指令通過輸出功能傳輸給對應的設備.

4) 自檢功能分為上電BIT和周期BIT，上電BIT主要在上電時執(zhí)行芯片、處理器、傳感器狀態(tài)等信息的自檢，周期BIT主要在正常工作、安全保護或失效保護時執(zhí)行電流、溫度等信息自檢.

5) 模式管理，根據(jù)飛行器管理計算機(VMC)的命令進行模式切換.例如，上電模式、正常工作模式、安全保護模式、失效保護模式、下電模式、地面維護模式.

Fig. 13 RNL requirement template圖13 RNL需求模板

6) 故障處理，根據(jù)不同類別的故障處理指令進行處理.

7) 存儲功能是將電磁閥的開關次數(shù)、電機壽命、電磁閥壽命、電流等信息進行存儲.

8) 輸入功能是將VMC的指令、溫度傳感器采集的溫度、壓力傳感器采集的壓力還有旋轉變壓器采集的角速度和角位置等信息進行接收.

9) 輸出功能包括：將周期自檢信息或者將上電自檢信息進行接收，準備傳輸給VMC；將存儲在存儲器中的信息下載到地面檢測設備中，將控制功能中傳輸過來的控制指令傳輸?shù)酵獠吭O備(電機、電磁閥、加熱器)中從而控制電機的轉速、電磁閥的開關和加熱器的開關；將接收到的周期自檢或上電自檢信息或者故障情況傳輸給VMC.

AACS的外部設備有溫度傳感器、壓力傳感器、旋轉變壓器、電機、電磁閥、加熱器、VMC、地面維護設備、機上電源.VMC主要功能是發(fā)送上電指令，接受ACC反饋的上電和周期自檢數(shù)據(jù)，決策并發(fā)送正常工作、故障清除等指令給ACC.

我們對案例應用RNL需求建模.

首先，對系統(tǒng)需求進行層次分解，將系統(tǒng)功能劃分為3層，最頂層為飛機空氣增壓系統(tǒng)，細分為二級子系統(tǒng)：初始化功能、供電功能、控制功能、存儲功能、輸入功能、輸出功能等.供電功能可劃分為ACC供電和RIU供電；存儲功能可劃分為參數(shù)記錄，存儲和存儲下載；輸入功能可劃分為VMC指令輸入、溫度傳感器采集、壓力采集和旋轉采集.飛機空氣增壓系統(tǒng)的需求模板層次結構如圖13左側所示.

在系統(tǒng)層次分解的基礎上，分別按照表5～7中對應的需求模板完成需求規(guī)約，完善輸入輸出信息、功能需求、約束信息等.圖13右側為控制功能的RNL需求.首先描述系統(tǒng)的基本信息，如中文名、英文名(來自領域詞庫和數(shù)據(jù)字典)、描述信息.然后在功能需求中詳細描述功能行為的執(zhí)行順序，在接收到閥板溫度、氣體出口溫度和閥板壓力等數(shù)據(jù)后，執(zhí)行計算PWM、發(fā)送PWM波信號等8步操作.其中第4步中調用了共享功能需求“計算PWM”;第5,6步分別為發(fā)送和調用行為句式;第7步中根據(jù)系統(tǒng)參數(shù)值判斷當前系統(tǒng)狀態(tài)，發(fā)送信號控制對應外部設備.

使用RNL插件進行需求建模后，通過RNL2SysML轉換工具，自動生成AACS的SysML初始系統(tǒng)模型.AACS的層次結構視圖BDD圖如圖14所示，正確轉換了需求模板中的3層結構.

Fig. 14 Block definition diagram of AACS圖14 飛機空氣增壓系統(tǒng)的BDD圖

Fig. 15 Internal block diagram of AACS圖15 飛機空氣增壓系統(tǒng)的IBD圖

圖15為RNL2SysML工具生成的AACS的最頂層的IBD圖，描述了二級功能之間的交互關系.例如，二級功能的輸入功能傳輸VMC下達的自檢指令，初始化指令模式切換指令，并將溫度、壓力、電機轉子的角速度和角位置傳遞給控制功能傳輸，輸出功能中將控制功能中傳輸過來的控制指令傳輸?shù)酵獠吭O備、電機、電磁閥、加熱器中從而控制電機的轉速、電磁閥的開關和加熱器的開關.頂層系統(tǒng)Block中包含了所有二級功能的實例作為Property，數(shù)據(jù)端口建模為Port，二級功能通過Port屬性與其他功能進行連接.

Fig. 16 Activity diagram of AACS control function圖16 AACS控制功能活動圖

圖16為RNL2SysML工具生成的飛機空氣增壓系統(tǒng)的控制功能的活動圖，控制功能是AACS最重要的功能，主要控制電機、電磁閥和加熱器，將三者的控制指令通過輸出功能傳輸給對應的設備.當接收到傳感器采集的閥板溫度、氣體出口溫度以及閥板壓力后，調用計算PWM，發(fā)送PWM波信號給VMC，之后選擇電磁閥信號，根據(jù)氣體出口溫度判斷當前氣罐溫度的高低，若氣體出口溫度大于15℃，則依次關閉加熱器，若氣體出口溫度小于15℃繼續(xù)判斷，若氣體出口溫度小于4℃，則依次發(fā)送打開加熱器的信號.該功能需求包含多重嵌套的判斷邏輯，需求中的多個條件被轉換為帶有guard活動邊的DecisionNode，發(fā)送接收數(shù)據(jù)被轉換為輸入輸出栓pin.

問題1.使用基礎的分類指標來評估候選術語提取方法，分別為精確率(Precision)、召回率(Recall)與F1-measure.當前任務是確定候選術語是否屬于基準術語表.基準術語表先由2名研究者對所有案例的需求文本進行標注，然后由領域專家審查決定基準數(shù)據(jù).屬于基準術語表的候選術語為真正例(true positives,TP),不屬于基準術語表的候選術語為假正例(false positives,FP)，本文方法未提取出的基準術語為假負例(false negatives,FN).Precision,Recall和F1-measure的計算方法為

Precision=TP(TP+FP)，

(2)

Recall=TP(TP+FN)，

(3)

(4)

將本文提出方法與典型的通用候選術語提取方法Pos-1[25]、Pos-2[26](如表9所示)、Dep[27](僅使用基于依存句法規(guī)則提取候選術語)進行比較.

Table 9 Glossary Extraction Methods表9 術語提取方法

本文的候選術語提取方法共產生1 443個候選術語.圖17展示了術語提取方法的評估結果.實驗結果表明:在保證精確率相對不變的情況下，本文方法的召回率最高，分別提高了30.0%以及22.9%;在精確率方面，本文方法相對于Pos-1以及Pos-2方法提高了1.2%，0.2%，相對于Dep方法降低了5.4%.

Fig. 17 Evaluation result of glossary extraction method圖17 術語提取方法評估結果

對于安全關鍵信息物理融合系統(tǒng)中的需求術語提取工作，召回率是比精確率更為重要的指標，因為低召回率意味著遺漏了許多原本應當加入領域詞庫和數(shù)據(jù)字典中的術語，而低精確率僅僅意味著提取了許多不符合要求的假術語.根據(jù)領域專家的意見，工程師刪去提取出的假術語的難度要遠遠小于再次檢查需求文檔、補充遺漏術語.我們的方法具有更好的召回率，因此具有更好的實踐意義.

問題2.表10為AACS系統(tǒng)的SysML模型數(shù)據(jù)統(tǒng)計.SysML模型元素統(tǒng)計分為3個部分：1)描述靜態(tài)功能架構的模型元素，涉及到BDD和IBD中的Block元素，以及沒有在圖上顯示的自定義數(shù)據(jù)類型；2)描述系統(tǒng)動態(tài)行為的元素，涉及到ACT中的ActivityNode元素；3)描述非功能屬性的元素，涉及到ConstraintRequirement元素.由表10可知，案例生成的SysML模型對于系統(tǒng)需求的覆蓋率較高.

Table 10 Statistics of Elements表10 模型元素統(tǒng)計信息

我們將RNL2SysML工具與現(xiàn)有的一些工具，如CM-Builder[28]，DC-Builder[29]，UMLG[30]，aToucan，ABCD[31]等進行對比，通過比較常用建模概念的覆蓋程度以評估工具的有效性，如表11所示.從表11中可以看出：

1) 所有的工具都可以生成UML或SysML中類(ClassBlock)的概念.對于組成關系，CM-Builder和UMLG均不能表示.

2) 只有ABCD和RNL2SysML支持對功能需求的轉換，而ABCD是通過在類圖中對類之間的關系添加注解來表示行為，并不是通過活動圖等行為視圖來表示.

3) 由于其他工具均生成的是UML圖，對于安全關鍵系統(tǒng)中常見的內部事件交互，只有RNL2SysML通過IBD圖可以支持.

Table 11 Comparison with Existing Tools表11 RNL2SysML與其他模型轉換工具的功能對比

4) 本文所提工具通過Profile集成了對非功能屬性的表示，以及給出從需求文本分配到圖形元素的追蹤關系.

問題3.為了評估方法與工具的實用性，我們設計了人工參與的對照實驗，參與對象為計算機學院不同年級的學生以及合作科研單位的系統(tǒng)工程師，分為系統(tǒng)工程師組和學生組，每組2人.實驗步驟為：

1) 以飛機空氣增壓系統(tǒng)案例為訓練案例，對所有參與者進行共計2 h的RNL2SysML原型工具的使用講解培訓.后續(xù)過程中，如果參與者遇到問題時，可以進行提問.

2) 給定2個工業(yè)案例的需求，要求參與者依次完成4項任務.任務1，建立數(shù)據(jù)字典、領域詞庫；任務2，填寫RNL模板；任務3，一鍵生成SysML模型；任務4，手工建立與任務3中一致的SysML模型.組內通過分工加快進度，并交叉確認結果.

3) 如表12所示，對參與者的任務用時進行統(tǒng)計，并收集參與對象的反饋意見.其中“X”代表待定，表示本文方法結合AI，其中的RNL模板填寫目前仍需要人工參與.

實驗結果表明：

1) 本文方法在術語推薦和建立SysML模型階段的平均用時最短(<1 min)，且遠遠低于全人工操作所需的時間(>5 h).

2) 在所有案例中，系統(tǒng)工程師組的用時均小于學生組，反映出具備更多專業(yè)知識的參與者可以更快地掌握需求模板方法和原型工具的使用.

3) 根據(jù)參與者的反饋，手工完成初步設計模型對于所有參與者均有較大難度，反映出從需求到設計之間的鴻溝.由于對SysML語言的理解程度不同，多個參與者手工建立的模型往往也不一致，采用本文方法可以降低不一致性，還具備學習成本低、實用性強的特點，對于實際案例具有積極意義.

Table 12 Execution Time of Case Studies表12 案例執(zhí)行時間統(tǒng)計

5.3 適用范圍與局限性分析

首先，限定自然語言需求規(guī)約方法比較適用于CPS系統(tǒng)的需求捕獲和概要設計階段.例如，可以直接采用RNL需求模板記錄需求，或者從需求文檔中獲得RNL需求.

其次，基于自然語言處理的術語推薦方法比較適用于需求術語分散于需求文檔各處的情況.例如，針對軟件需求以需求文檔、會議記錄和談話記錄等文本方式存在時，可以使用本文方法推薦出候選術語，然后通過工程師篩選得到領域術語和數(shù)據(jù)字典.

最后，基于自然語言處理的術語推薦方法的實驗評估階段，主要針對基于語言學的最新方法進行實驗對比.由于本文主要針對特定領域，存在語料庫有限的不足[32]，因此不具備使用機器學習或者深度學習方法[33-34]的條件.

6 相關工作

本文的相關工作主要包括3部分：需求工程中的人工智能(AI)方法應用、限定自然語言需求建模、設計模型的轉換與生成.

6.1 需求工程中的AI方法應用

目前，AI技術主要應用在術語提取、需求優(yōu)先級排序、需求分類、領域模型抽取等任務中.

Berry等人[35]提出了基于頻率的方法來識別在需求中反復出現(xiàn)的術語；Matsuo與Ishizuka[36]使用單詞和單詞序列的共現(xiàn)頻率來識別關鍵術語.

Dwarakanath等人[37]使用句法解析來提取需求文檔的短語，然后基于啟發(fā)式方法和基于頻率的統(tǒng)計信息過濾結果.

Perini等人[38]提出一種需求優(yōu)先級排序方法(case-based ranking, CBRank)，該方法將項目參與者的偏好與通過機器學習算法計算出的需求排序近似值相結合，效果較好.

Winkler等人[39]提出基于卷積神經網(wǎng)絡的自動需求分類方法，將需求文檔中的“需求”和“補充信息”進行區(qū)分.

Arora等人[40]提出了一種基于主動學習的方法，不斷從用戶反饋中學習相關度知識，過濾NLP提取結果中的多余信息，從而提高自動提取領域模型的準確度.

此外，劉璘等人[41]提出了自動化的非功能需求識別和分類方法，基于語義距離和相似度計算，將非功能需求語句分為性能、可靠性、可用性、安全性、可維護性這5類.

上述工作主要應用于英文需求文本，由于中英文之間存在較大差異性，這些工作無法直接應用于中文需求文本.目前，面向中文需求文本的自動化分析工作較少.

6.2 限定自然語言需求建模

RollsRoyce公司的Mavin等人[42]針對用戶需求難以描述和表達的問題，在大量工程經驗的基礎上，提出了一種EARS(easy approach to requirements syntax)方法進行需求規(guī)約.該方法通過將功能需求分為6種類型，有效簡化了需求的描述與表達難度，同時有效降低自然語言的二義性.類似的有Rupp等人提出的Rupp模板[43]將功能需求分為3類.但以上模板只對功能需求進行了分類和描述，沒有全面地包含嵌入式系統(tǒng)的靜態(tài)結構、動態(tài)行為和非功能屬性.

Holtmann等人[44]針對汽車工程領域的軟件系統(tǒng)的需求規(guī)約展開研究，提出了一種受控自然語言(controlled natural language, CNL)用于汽車領域嵌入式軟件需求描述，CNL還可以實現(xiàn)需求的自動化驗證，以及對需求的不一致性和不完整性進行檢測.

岳濤等人[17-18]提出了一種改進的受限用例建模方法(restricted use case model, RUCM)，RUCM包含一個相對完善的用例文本說明模板和系列自然語言限定規(guī)則(restricted rules)，使得用例描述更加易于理解和精確，減少歧義，并且可以自動化產生分析模型.目前，已有相應的研究方法和工具支持將RUCM的用例模型自動轉換為初步的UML分析模型(類圖、活動圖、順序圖等).

針對RUCM較難描述機載嵌入式軟件的安全性需求的不足，吳際等人[45]對RUCM進行了擴展，添加相應的模板與限定規(guī)則，提出SafetyRUCM，使其支持安全性需求的規(guī)范化描述，但主要是從用例的角度進行需求描述.

王政等人[20]面向航天型號軟件，提出了航天需求描述語言SPARDL，能夠清晰、無二義地描述航天軟件需求.SPARDL包括數(shù)據(jù)字典、模塊和模式圖3個部分，其中核心為模式圖.經實踐證明，SPARDL能在航天型號研究過程中有效地提高航天嵌入式軟件的質量，但SPARDL采用形式化需求描述方法，實踐難度較大，且針對航天信號軟件設計，通用性不足.

另外，面向對象管理組織OMG在正在制定的SysML2.0[21]版本中也提出了限定自然語言需求建模的思想，旨在提高需求描述的精確性和有效性.

6.3 需求表達到設計模型的轉換與生成

已有的需求表達到系統(tǒng)設計模型的轉換主要包括基于自由文本的方式和基于限定自然語言模板的方式.

1) 基于自由文本

Bajwa等人[15]提出從自然語言到OCL約束的自動轉換方法.

Letsholo等人[16]提出TRAM方法將自由文本需求轉換到UML類圖.

Abdessalem等人[31]提出ABCD(automatic builder of class diagram)方法，定義了一千多種模式并通過NLP技術從自由文本中抽取概念，并自動轉換到UML類圖.

劉璘等人[46-47]提出基于依存文法的需求文本策略依賴關系抽取方法，構建出i*框架中的SD模型.

2) 基于限定文本(restricted text)

岳濤等人[17-18]針對傳統(tǒng)UML用例規(guī)約描述存在的不足提出了基于用例建模方法RUCM，并使用aToucan工具將RUCM的用例模型自動轉換為初步的UML分析模型(類圖、活動圖、順序圖等).

何嘯等人[48]提出了基于模板的生成方法，包括中間元模型、從模板到中間元模型的folding算法、從中間元模型到目標模型的unfolding算法.該方法提供了不針對特定語言的、通用的模型生成思路.

Ballard等人[49]基于包含屬性、組成關系、狀態(tài)描述、狀態(tài)遷移等的簡單需求模板轉換到SysML塊定義圖和狀態(tài)機圖.

楊志斌等人[23-24]給出了基于限定中文自然語言需求的AADL模型自動生成方法.

Colombo等人[22]提出基于問題框架(problem frames)的需求分析并將需求規(guī)約轉換到SysML的方法，分別抽取Blackboard和Knowledge Source信息并不斷精化，將問題框架轉換到SysML模塊定義圖、活動圖等，生成早期設計模型.該研究主要考慮基于問題分解的方式獲得系統(tǒng)初始層次架構，還未考慮系統(tǒng)非功能特性.

相比于上述工作，本文主要針對中文自然語言需求；其次，在限定自然語言需求建模中，我們引入了基于AI的需求術語推薦方法；最后，本文考慮了安全關鍵CPS系統(tǒng)的非功能需求表達，即對SysML的安全性、可靠性擴展.

7 結束語

如何將自然語言需求和模型驅動開發(fā)方法進行有效鏈接，即實現(xiàn)自然語言需求到設計模型的自動或半自動轉換是模型驅動開發(fā)方法在安全關鍵信息物理融合系統(tǒng)設計與開發(fā)中實際應用的一個主要挑戰(zhàn).本文面向安全關鍵信息物理融合系統(tǒng)，結合自然語言處理技術對需求文本進行術語抽取，通過用戶的簡單編輯后將術語加入限定自然語言需求模板的需求規(guī)約方法中，構建安全關鍵信息物理融合系統(tǒng)需求模型，然后自動轉換到面向多視圖的SysML模型.

未來的研究工作將包括：1)檢測原始文本需求與限定自然語言需求模板之間的一致性，并根據(jù)需求文本推薦相一致的需求模板;2)對生成SysML模型進行形式化驗證;3)探索將用戶反饋作為方法的二次輸入，優(yōu)化需求推薦的準確度;4)增加工業(yè)界案例數(shù)量，對本文方法進行更多的實驗評估;5)完善自動術語抽取的基礎評價體系;6)結合基于統(tǒng)計與基于規(guī)則的方法，收集更多領域語料以訓練模型.