發(fā)布者：凱思軟件發(fā)布日期：2023-09-05瀏覽量：
仿真已經(jīng)成為大多數行業(yè)大規模采用基于模型的系統工程（MBSE）和基于模型的設計（MBD）工具的至關(guān)重要的因素。與此同時(shí)，實(shí)用的需求工程工具在以文檔需求規格為主的生命周期管理之外并未得到顯著(zhù)發(fā)展，這使得需求并未得益于基于模型的仿真工具。需求在環(huán)（RIL）仿真已被提議用來(lái)擴展MBSE和MBD框架，允許系統工程師用一種正式的語(yǔ)言來(lái)描述文本需求，并且可以與系統模型一起執行和仿真。需求在環(huán)仿真可允許基于需求語(yǔ)義生成離散時(shí)間系統行為，以及檢查狀態(tài)機等其他行為模型是否符合相關(guān)的系統需求。本文介紹了需求在環(huán)仿真的原則，并通過(guò)起落架系統案例講述了其所具備的優(yōu)勢。這項工作尤其彰顯了STIMULUS工具所具備的強大實(shí)力，包括檢測現實(shí)系統中錯誤的，缺失的或沖突的需求，以及測試其基于模型的需求規格是否符合相關(guān)需求。
引言
來(lái)自汽車(chē)、鐵路、航空電子、國防、航天、能源或醫療等關(guān)鍵安全領(lǐng)域的所有行業(yè)標準，都將需求置于開(kāi)發(fā)和驗證流程的核心，其中需求工程工具通常用來(lái)管理以文檔為主的需求規格的生命周期。為了克服純文本需求規格在處理系統日益增加的復雜性方面的限制，我們推出了基于模型的系統工程（MBSE）[1]和基于模型的設計（MBD）[2]工具，并在大多數行業(yè)中進(jìn)行了大規模的采用。仿真顯然是成功實(shí)現上述需求的關(guān)鍵因素，因為其為早期分析和驗證打開(kāi)了機遇之門(mén)。
然而，基于模型的系統工程和需求工程工具之間的耦合仍然十分微弱。當前的行業(yè)實(shí)踐通常僅限于需求和模型之間的可追溯性流程。從仿真的角度來(lái)看，需求的執行語(yǔ)義基本上還尚未得到利用，盡管我們已在這個(gè)領(lǐng)域開(kāi)展了一系列的研究工作[3]。
需求在環(huán)仿真[4]旨在將實(shí)時(shí)功能需求轉變?yōu)樾问交?，但仍然是文本的，可執行的模型。這些模型可以作為更大模型的一部分進(jìn)行整合，通常是作為原理圖捕獲的系統架構，并與其他行為模型協(xié)同仿真。執行引擎依賴(lài)于約束求解技術(shù)來(lái)生成離散時(shí)間仿真，其中我們通常將需求解讀為信號上的約束。
需要值得注意的是，需求和其他行為模型通常攜帶互補信息，因為它們捕獲了不同的抽象級別。舉例來(lái)說(shuō)，安全需求可能會(huì )指定系統應該做什么，例如，在給定的延遲內對環(huán)境中的某些STIMULUS做出反應。因此，需求通常是部分的且非確定性的。相比之下，傳統的行為模型，如狀態(tài)機等，可能會(huì )更專(zhuān)注于如何進(jìn)行反應，從而以更確定性的方式確保這種反應延遲。
需求在環(huán)仿真的應用包括兩個(gè)方面。一方面，形式化需求可以作為系統的許多不同行為的生成器，以調試和驗證在開(kāi)發(fā)流程的早期階段的"內容"。另一方面，一旦模型可用，無(wú)論是詳細的需求規格還是實(shí)現模型，相關(guān)需求都可以作為觀(guān)察者用來(lái)開(kāi)展測試和驗證的"方法"與"工具"。
在本文中，我們介紹了需求在環(huán)仿真的基本要素，并且我們在起落架客戶(hù)案例[5]中闡述了它的使用，該案例提供了一個(gè)具有代表性大小和復雜性的現實(shí)系統。我們展示了識別錯誤的，缺失的和沖突的需求以及驗證可執行模型與其需求的能力。由于起落架的需求規格同時(shí)使用了文本需求，狀態(tài)機以及原理圖的混合信息，因此我們利用STIMULUS工具捕獲了完整的需求規格，并探討了其與第三方工具（如需求管理，MBSE或MBD工具等）的集成。
需求在環(huán)的基本要素
需求在環(huán)仿真致力于解決動(dòng)態(tài)系統的功能需求。起落架客戶(hù)案例中的一個(gè)典型示例是以下的高級需求：“當操作桿命令為放時(shí)，所有起落架均應在15秒內完全展開(kāi)，并且所有艙門(mén)應關(guān)閉?！?/strong>此類(lèi)需求通常描述了系統隨時(shí)間變化的邏輯和數值屬性的組合。它們與非功能需求（如可用性或可靠性等）形成鮮明對比，后者并不受需求在環(huán)支持。
建模功能需求
進(jìn)行需求在環(huán)仿真的前提是能夠捕獲此類(lèi)需求的精確語(yǔ)義。為此，STIMULUS提供了一套預定義的句子模板，可以自由組合以構建文本需求，如圖1所示。句子模板可支持多種語(yǔ)言版本，用戶(hù)可以擴展預定義模板集以適應特定領(lǐng)域的需求。
圖1. 使用模板需求規格化的起落架系統需求
模板參數既可以參考標量表達式也可以參考語(yǔ)句，例如，“當......時(shí)”模板的條件和<主體>參數。每個(gè)模板的語(yǔ)義都通過(guò)等式和/或狀態(tài)機進(jìn)行形式化定義。例如，“是”模板定義了多態(tài)的數學(xué)等式，而“當......時(shí)”模板定義了狀態(tài)機，當條件為真時(shí)，激活<主體>語(yǔ)句，如圖2所示。
圖2. “當......時(shí)”模板的語(yǔ)義
仿真需求
執行需求的形式化語(yǔ)義的能力是需求在環(huán)仿真面臨的主要挑戰。STIMULUS的執行引擎源于Lutin[6]，這是一種原創(chuàng )語(yǔ)言，其完美結合了約束和正則表達式，以指定通用測試場(chǎng)景，以及Lurette[7]，這是一種執行引擎，可以從Lutin模型自動(dòng)生成許多測試向量。此外，作者還指出了在需求工程中使用此類(lèi)工具的巨大優(yōu)勢[12]。
STIMULUS按如下方式將這些原則擴展到了相關(guān)需求中：
需求規格語(yǔ)言對約束和狀態(tài)機進(jìn)行了完美結合，采用了模式自動(dòng)機[8]的同步語(yǔ)義，以正確處理分層和并行組合；
編譯器將一組采用這種語(yǔ)言進(jìn)行表達的需求轉化為一組有時(shí)鐘的約束，遵循Lucid Synchron[9]的原始轉化模式；
模擬器將時(shí)鐘解譯為一個(gè)控制結構，以收集每個(gè)控制點(diǎn)[4]處的活動(dòng)約束集，這可能會(huì )在執行每個(gè)（離散時(shí)間）步驟時(shí)有所變化；
求解器計算活動(dòng)約束的可能解空間，這是一組強耦合的布爾、數值和時(shí)間方程[10]的集合，并選擇其中一個(gè)解來(lái)計算系統輸出；
調試器允許檢查信號值、活動(dòng)需求的亮點(diǎn)，以及改編自[11]的高級探索特性，以解釋為什么信號在精確的時(shí)間點(diǎn)有給定的值。
在此背景下，仿真意味著(zhù)生成滿(mǎn)足需求約束的執行追蹤，即可能的系統行為。由于需求規格本質(zhì)上通常是部分的，因此并非確定性的，這樣的行為并非唯一。運行多次仿真將產(chǎn)生多種不同的行為，這對于測試自動(dòng)化至關(guān)重要，相關(guān)內容將在第4節中進(jìn)行深入探討。
圖3顯示了圖1中由STIMULUS生成的高級需求可能的執行追蹤。由于我們并未指定起落架的伸出序列，艙門(mén)和起落架可能會(huì )經(jīng)歷不同的狀態(tài)（定義為枚舉類(lèi)型），但一旦HandleCommand輸入切換為放，艙門(mén)和起落架在預期的延遲內達到他們預期的狀態(tài)（分別為關(guān)閉和展開(kāi)）。
本文的一個(gè)主要目標是展示如何將這個(gè)高級需求細化為更低級別的需求，這些需求將指定起落架收回和伸出序列的詳細信息。
圖3. 圖1中需求的可能的執行追蹤
調試需求
盡管需求的聲明性質(zhì)可提供如原子性、可組合性或可測試性等的眾多優(yōu)勢，但是，聲明性語(yǔ)言通常更難以進(jìn)行調試。由于找出bug的原因比修復它需要花費時(shí)間更長(cháng)，因此STIMULUS提供了多種調試功能來(lái)探索仿真的空間和時(shí)間維度。
標準的調試功能已根據相關(guān)需求進(jìn)行了適應，比如高亮顯示活動(dòng)/非活動(dòng)需求，或者在任何時(shí)間點(diǎn)監控任何變量。此外，許多原創(chuàng )功能專(zhuān)門(mén)針對需求的聲明性質(zhì)給出了解決方案，以支持檢測三種類(lèi)型的錯誤：
錯誤的需求（正確性）：仿真運行良好，但仿真圖并未顯示預期的行為，這意味著(zhù)一個(gè)或多個(gè)需求并未傳達出架構師的真正意圖。在這種情況下，高級探索功能有助于在任何時(shí)間點(diǎn)從任何變量中找出所涉及的需求。
缺失的需求（完整性）：仿真運行良好，但部分仿真圖包含了虛線(xiàn)，意味著(zhù)在這些時(shí)間段內，沒(méi)有活動(dòng)的需求對它們進(jìn)行定義。這可能是為了留下一些自由度以進(jìn)行實(shí)施選擇，或者可能是缺失需求的跡象。
沖突的需求（一致性）：仿真在某個(gè)時(shí)間點(diǎn)停止，意味著(zhù)其中有一組需求是存在矛盾的，也就是說(shuō)，一組約束沒(méi)有解。在這種情況下，求解器可自動(dòng)報告沖突需求的最小集合。
其他建模方面
一些其他建模特性提高了形式化需求規格的一致性，以及它們在第三方工具中的集成。
原理圖語(yǔ)言可允許定義系統架構，這與任何MBSE或MBD工具類(lèi)似。系統定義接口（輸入、輸出、參數）和行為，既可以是原理圖，也可以是需求和狀態(tài)機的組合，或者是外部的FMI組件。原理圖可以從其他工具導入，而形式化的需求可以與需求管理工具同步。
術(shù)語(yǔ)表允許定義可以在不同組件之間進(jìn)行分享的系統變量。對于每個(gè)變量，術(shù)語(yǔ)表可選地指定數據類(lèi)型、物理單位和/或物理維度、數值范圍或某些默認行為。類(lèi)型系統支持推斷和多態(tài)性，這對于構建通用庫，以及在不提供任何類(lèi)型信息的情況下檢查需求的一致性都是非常實(shí)用的。
需求在環(huán)仿真對起落架需求的處理
起落架系統[5]旨在根據航空器駕駛員的指令，控制三個(gè)起落架的伸出和收回序列。其主要由三部分組成。航空駕駛員界面提供了一個(gè)操縱裝置來(lái)指揮起落架的位置，以及作為顯示機械狀態(tài)的顯示器。數字部分負責將航空器駕駛員的指令轉化為電子命令，傳遞給物理部分。物理部分由三套起落設備組成，包括起落架、艙門(mén)，以及一些如電磁閥、模擬開(kāi)關(guān)、液壓缸，以及用于捕獲機械狀態(tài)的傳感器等的電機設備。
圖4. 起落架系統架構
圖4的原理圖介紹了航空器駕駛員、數字部分和物理部分之間的交互?？紤]到安全原因，數字部分是一個(gè)冗余系統，其運行兩個(gè)實(shí)例的相同計算模塊。這個(gè)模塊包括伸出和收回序列的控制器，以及負責識別和消除無(wú)效傳感器的健康監控系統。
整個(gè)架構在STIMULUS中以層次化的原理圖進(jìn)行指定。術(shù)語(yǔ)表定義了所有的連接/接口信號，并且結構類(lèi)型允許信號的復用，例如，DoorsClosedSensors是一個(gè)3x3的布爾矩陣，用于捕獲每個(gè)起落架套裝的三重傳感器。
形式化的需求可以分配給系統架構的任何級別。例如，圖1的高級需求分配給了數字部分，并且詳細的細化需求可以分配給基礎組件，如控制器和物理設備等。
物理部分的需求
原始需求規格以自由文本的形式介紹了物理設備的行為。對于每臺設備，此行為已經(jīng)被捕獲為一組形式化的需求，在此可以單獨進(jìn)行仿真。例如，模擬開(kāi)關(guān)的自由文本描述如圖5所示。
“每次航空器駕駛員移動(dòng)操縱桿時(shí)，開(kāi)關(guān)都會(huì )關(guān)閉，并保持關(guān)閉20秒。此時(shí)長(cháng)過(guò)后，開(kāi)關(guān)會(huì )自動(dòng)變?yōu)榇蜷_(kāi)狀態(tài)。在閉合位置時(shí)，開(kāi)關(guān)將數字部分的電氣指令傳輸給通用電磁閥。在打開(kāi)位置，電氣指令沒(méi)有被發(fā)送到電磁閥。由于慣性原因，從兩種狀態(tài)進(jìn)行轉換需要一定的時(shí)間：從打開(kāi)到閉合需要0.8秒，從閉合到打開(kāi)需要1.2秒?！?
圖5. 模擬開(kāi)關(guān)非形式化需求規格
圖6. 模擬開(kāi)關(guān)的形式化需求
圖6給出了模擬開(kāi)關(guān)的形式化需求，而圖7顯示了一個(gè)可能的仿真。HandleMove信號的行為受到約束，以發(fā)出隨機脈沖，而輸入信號是具有隨機值的自由變量。每次發(fā)出HandleMove信號時(shí)，開(kāi)關(guān)都會(huì )關(guān)閉，輸入信號會(huì )傳輸到輸出信號。
然而，對仿真圖進(jìn)行深入觀(guān)察會(huì )發(fā)現一個(gè)錯誤的行為，因為在t=50s時(shí)的HandleMove脈沖應該將開(kāi)關(guān)保持在關(guān)閉狀態(tài)，直至t=70s。將第二個(gè)需求的條件替換為“狀態(tài)變?yōu)殛P(guān)閉或HandleMove變?yōu)檎妗笨梢越鉀Q這個(gè)問(wèn)題。
圖7. 可能的模擬開(kāi)關(guān)需求的仿真結果
數字部分的需求
原始的伸出序列需求規格在圖8中給出。其本身并不是一組需求，而是一個(gè)標準的情景，因為其描述了在完成一個(gè)完整的伸出序列過(guò)程中，數字控制器發(fā)送的命令序列以及物理部分的反應。此外，附注特別說(shuō)明，這個(gè)標準的序列可以在任何時(shí)候被反向命令打斷，而且這個(gè)序列會(huì )在被打斷的地方恢復。
盡管這個(gè)需求規格非常全面，但其并沒(méi)有提供統一且可測試的需求來(lái)描述系統在任何時(shí)間點(diǎn)應執行的操作。深入分析此類(lèi)需求是一個(gè)非常艱難的過(guò)程，并沒(méi)有什么神奇的簡(jiǎn)單方法：我們是通過(guò)不斷地試驗、錯誤和修正進(jìn)行的。然而，事實(shí)證明，仿真在檢測連續的錯誤和向圖9中的形式化需求集合進(jìn)展的過(guò)程中是至關(guān)重要的。
伸出序列。起落架的伸出可分解為一系列基本動(dòng)作。當起落架鎖定于收起位置，且艙門(mén)鎖定于關(guān)閉位置時(shí)，若航空器駕駛員將操縱桿設置為“放”，則軟件應產(chǎn)生以下一系列動(dòng)作。
激勵常規電磁閥將指令單元分離，從而向作動(dòng)電磁閥傳遞液壓力。
激勵艙門(mén)開(kāi)啟電磁閥。
當三個(gè)艙門(mén)均抵達開(kāi)啟位置時(shí)，激勵起落架釋放電磁閥。
當三個(gè)起落架被鎖定，停止激勵起落架釋放電磁閥。
停止激勵艙門(mén)開(kāi)啟電磁閥。
激勵艙門(mén)關(guān)閉電磁閥。
當三個(gè)艙門(mén)均抵達關(guān)閉位置且鎖定，停止激勵艙門(mén)關(guān)閉電磁閥。
最終停止激勵常規電磁閥。
反向指令應隨時(shí)均對以上動(dòng)作序列具有中斷效果（如釋放序列中遭遇收起指令和收起序列中遭遇釋放指令）。在此類(lèi)情況下，有關(guān)場(chǎng)景由中斷處繼續執行。
圖8. 傳出序列的非形式化需求規格
圖9. 伸出序列的形式化需求
需求仿真分析
一旦所有軟件和物理需求都已形式化并分配給系統架構中的適當組件，我們就可以仿真完整的系統行為。從建模的角度來(lái)看，這就是與現有的MBSE/MBD工具的連接發(fā)揮其全部作用的地方，因為系統架構通?？梢愿鶕鄳男枨笥?strong style="margin:0px;padding:0px;outline:0px;max-width:100%;box-sizing:border-box !important;overflow-wrap:break-word !important;">STIMULUS導入。由于需求的分配被保留，系統架構師可以在他們的標準MBSE工具中對架構進(jìn)行建模，并在非常早期的階段在STIMULUS中對其進(jìn)行仿真，而無(wú)需等待更詳細的行為模型。
可能的仿真如圖10所示。HandleCommand信號首先從放切換到收，然后，在收回序列完成之前，切換回放，以激活伸出序列。我們可以看到，反指令得到了妥善的管理。收起序列一直運行到所有的艙門(mén)都打開(kāi)，所有的起落架都在操縱以回收。然后啟動(dòng)了伸出序列。由于所有的艙門(mén)都已經(jīng)打開(kāi)，伸出序列立即開(kāi)始操縱以展開(kāi)起落架，一旦展開(kāi)起落架，就完成了相應的序列，關(guān)閉了艙門(mén)。
圖10. 可能的起落架需求仿真
圖1中的高級需求，作為數字部分的觀(guān)察者，也得到了滿(mǎn)足。換言之，伸出序列的詳細需求是對其的優(yōu)異細化。
然而，圖11中的第一個(gè)安全性需求在時(shí)間t=10.3s處遭到違反，因為數字部分向艙門(mén)發(fā)送了相互矛盾的指令。在一個(gè)時(shí)間點(diǎn)，物理系統被要求同時(shí)打開(kāi)和關(guān)閉艙門(mén)。STIMULUS會(huì )自動(dòng)報告這個(gè)沖突，并給出精確的診斷，從而識別出一組沖突的需求和沖突的瞬間。
圖11. 伸出和收回序列的安全需求
由于篇幅原因以及作者對游戲感的缺乏，讀者被邀請代入系統架構師的角色，提出一個(gè)詳細的修改需求以避免這種沖突的建議。在第二步中，讀者被邀請在不進(jìn)行任何仿真測試的情況下，思考他們對這種改變抱有多大的信心。
針對需求進(jìn)行模型測試
一旦驗證通過(guò)，形式化需求可以轉化為觀(guān)察者，用來(lái)測試任何模型的需求規格，或者起落架的軟硬件實(shí)現。對于硬件在環(huán)（Hardware-In-the-Loop）仿真，觀(guān)察者被導出為FMI組件以監控測試工作臺并記錄違反的需求。對于模型或軟件在環(huán)（Model- or Software-In-the-Loop）仿真，FMI組件被從第三方MBSE/MBD工具導入STIMULUS，以構建測試套件并自動(dòng)化回歸測試。
在這個(gè)客戶(hù)案例中，我們已經(jīng)將一些數字和物理組件建模為狀態(tài)機，其中一些是由原始論文[5]提供的，以便根據需求測試需求規格模型。尤其是，我們返回到伸出序列的原始需求規格，因為人們可能認為，使用狀態(tài)機對這個(gè)序列及其中斷進(jìn)行建模是非常直觀(guān)的。
圖12展示了STIMULUS的分層狀態(tài)機模型，其中包含一個(gè)恢復轉換（由空箭頭標示）。如預期的那樣，對于完整的伸出序列的名義場(chǎng)景，狀態(tài)機工作正常。然而，這個(gè)模型并未正確處理反向指令，許多需求觀(guān)察者在此類(lèi)仿真中遭到違反。
與原始需求規格中的表述不同，序列不應該“從中斷的地方繼續”。實(shí)際上，恢復狀態(tài)依賴(lài)于艙門(mén)和起落架的物理狀態(tài)，并且應該為序列的每個(gè)狀態(tài)都添加特定的傳入轉換。再次，我們讓讀者提出新的需求規格，并找出缺失的轉換條件。最后，我們還指出，一個(gè)明智的原理圖控制器實(shí)際上可以從形式化的需求中得出，并提供一個(gè)優(yōu)異的備選狀態(tài)機。
圖12. 伸出序列的初級狀態(tài)機需求規格
可執行需求和模型的結合為基于模型的測試提供了一個(gè)良好的框架。特別是，形式化需求有助于設置一個(gè)測試線(xiàn)束來(lái)自動(dòng)化回歸測試。在這項工作中：
我們將數字控制器視為被測系統（SUT）。其可以是一個(gè)模型，例如狀態(tài)機，或一個(gè)外部的FMI組件；
我們將航空器駕駛員視為測試案例。命令可以被建模為約束，以生成各種測試場(chǎng)景（常規，反向命令）；
我們將物理部分視為測試存根。其可以是需求和狀態(tài)機的結合，并對SUT環(huán)境進(jìn)行仿真；
我們將數字控制器的需求視為測試預言，作為觀(guān)察者執行。
我們的結果顯示了對初始起落架和艙門(mén)位置的廣泛探索，以及它們對伸出和收回序列執行的影響，這些序列通?？偸菨M(mǎn)足圖1的高級需求。
結論
本客戶(hù)案例展示了對需求在環(huán)仿真的使用，對調試和驗證具有實(shí)際復雜性的典型網(wǎng)絡(luò )物理系統功能需求規格的應用。
研究結果表明，需求在環(huán)（RIL）仿真非常適合基于模型的系統工程方法，因為可以以一種一體化和一致性的方式來(lái)設計需求、架構和行為模型。尤其是，可以將給定系統的需求細化為其子系統的更低級別需求，直至定義行為模型。在細化過(guò)程的任何步驟，都會(huì )進(jìn)行仿真以檢查全局系統架構的一致性以及低級別需求和/或模型與高級別需求的合規性。
這提供了一個(gè)有效的基于模型的測試框架，其中需求輪流捕獲被測試系統、測試預言、測試用例或測試存根。測試執行引擎充分利用約束求解技術(shù)來(lái)探索各種環(huán)境場(chǎng)景和被測試系統的可能反應，從而實(shí)現全自動(dòng)回歸測試。盡管仿真無(wú)法確保探索的窮盡性，但其似乎是手動(dòng)測試的有限覆蓋率和自動(dòng)證明工具的有限采用率之間的有效權衡。
最后，這項研究的一個(gè)有趣結果涉及到故障分析。傳感器模型已經(jīng)擴展了概率故障，通過(guò)仿真驗證健康監控系統的需求。這一研究工作的初步成果非常鼓舞人心，為這一領(lǐng)域未來(lái)工作的開(kāi)展打開(kāi)了機遇之門(mén)。
