2、需求管理

需求是客戶為了解決某個問題或?qū)崿F(xiàn)某個目標所需要的能力或條件，它是對客戶需要、法規(guī)要求、性能指標以及設(shè)計參數(shù)的工程化描述，為各工程學科團隊提供了一種有效的溝通交流的方式，所有學科團隊共同的目標就是為了研發(fā)出滿足需求的產(chǎn)品，如果沒有需求或者需求不明確，那么我們可能開發(fā)出客戶根本不需要的產(chǎn)品，也可能出現(xiàn)對產(chǎn)品的過度設(shè)計或者欠設(shè)計，從而浪費了設(shè)計資源，最終導致產(chǎn)品質(zhì)量低下，無法被客戶所接受，可以說如果沒有需求或者需求不明確的話，那么后續(xù)的所有研制活動都將變的毫無意義。

需求的滿足和實現(xiàn)是復雜系統(tǒng)研制的根本目的，因為無論進行什么樣的活動，包括設(shè)計、仿真、試驗等等，其最終目的都是為了設(shè)計制造出滿足客戶需求的產(chǎn)品。因此，復雜系統(tǒng)的需求管理是設(shè)計、制造和客戶之間溝通的主要途徑。需求用來描述一個產(chǎn)品或一項服務(wù)的期望功能和特征，需求應該是能夠被清晰簡潔的表達出來，同時被客戶完全認可的信息。因而，需求管理的根本目的就是要把需求模型工程化和條目化，讓需求去指導產(chǎn)品的工程開發(fā)。

根據(jù)復雜系統(tǒng)產(chǎn)品研制的特點，需求模型可以分為四層：

第一層：客戶或采購方對復雜系統(tǒng)的技術(shù)要求，法規(guī)等（客戶需求層）；

第二層：總體技術(shù)要求（產(chǎn)品需求層）；

第三層：子系統(tǒng)技術(shù)要求（分系統(tǒng)需求層）；

第四層：設(shè)備零件設(shè)計要求（設(shè)備零件需求層）。

         

圖1. 需求模型的樹狀結(jié)構(gòu)

很多企業(yè)或工程師往往會錯誤的認為需求管理就是簡單的將需求進行條目化的文本描述和分類存儲，然而需求也應該有生命周期狀態(tài)，我們不僅要將需求進行條目化的描述和存儲，并且在不同的生命周期階段，我們需要定義不同的屬性來反映需求的狀態(tài)，同時每個階段需求的內(nèi)容和表現(xiàn)形式也有所不同。

在需求捕獲階段，當我們通過客戶訪談、問卷調(diào)查等一系列手段將“客戶需要”記錄下來時，這些“客戶需要”往往是模糊的、無法定量或者定性的描述，此時我們必須將這些“客戶需要”轉(zhuǎn)化為符合工程描述的需求，包括名稱、假設(shè)、來源等，同時添加作者、客戶、版本、優(yōu)先級等屬性，這時需求的生命周期狀態(tài)為已捕獲，其表現(xiàn)形式為單個需求條目；

在需求分析階段，我們通過功能定義、系統(tǒng)架構(gòu)等相關(guān)手段將客戶需求逐層分解和細化，形成不同層級的需求，此時相比已捕獲的需求來看，增加了層級、類型、相關(guān)需求等屬性，另外需求的內(nèi)容也比上一階段更加精細化；同時我們需要將這些需求按照層級和類型進行劃分形成需求的結(jié)構(gòu)樹；

在需求確認階段，我們經(jīng)過相應的確認流程后，相比需求分析階段，每條已確認的需求需要附加上需求的確認結(jié)果和參考，此時需求一經(jīng)確認即被凍結(jié)，此后的每個階段如果需要變更，就需要提交需求變更流程方可更改，更改后的需求會產(chǎn)生新的版本，并根據(jù)情況重新執(zhí)行捕獲或分析活動；

在需求分配階段，我們經(jīng)過系統(tǒng)架構(gòu)設(shè)計，將上層需求分配到下層產(chǎn)品，此時可能會產(chǎn)生衍生的需求，因此，相較需求確認階段，需求的種類會多出衍生需求這一類型；

在需求驗證階段，我們經(jīng)過一系列的工程設(shè)計和驗證，此時每條需求需附加驗證方法和依據(jù)，如仿真、測試或?qū)嶒灥取?/span>

需求模型的樹狀結(jié)構(gòu)的組織過程是通過鏈接來完成的，也就是內(nèi)部鏈接，內(nèi)部鏈接指的是需求與需求之間的鏈接。需求管理的目的是用設(shè)計方案，通過功能定義、邏輯分解等技術(shù)手段，通過變更管理、項目組織等過程，來完成對需求的滿足。因此，當某個對象發(fā)生變化的時候，我們需要對所受影響的包括需求模型在內(nèi)的各個元素進行分析，也就是需要建立外部鏈接：建立需求與系統(tǒng)中其他相關(guān)對象的鏈接。當前大部分企業(yè)或組織都以某種斷開連接的方式管理需求，如Excel電子表格、Word文檔以及獨立的需求工具等等，然而因為這些工具與產(chǎn)品生命周期的其余部分斷開連接，導致它們沒有能力影響設(shè)計，當需求或設(shè)計方面發(fā)生變化時，我們看不到這些變化帶來的影響/聯(lián)系，這就意味著我們的產(chǎn)品開發(fā)最終處于錯誤的位置，也就是不再符合要求。

圖3. 西門子Teamcenter集成化需求管理

通過Teamcenter中的集成化需求管理，我們可以使用其他產(chǎn)品構(gòu)件管理需求，允許這些需求參與更改、工作流、配置等，將需求從斷開連接的文檔帶入到生命周期中，在產(chǎn)品生命周期管理當中，我們可以有效地管理需求，確保它們與我們的產(chǎn)品開發(fā)流程相連接，以驅(qū)動設(shè)計交付，了解情況發(fā)生變化時它們的所帶來的影響，并了解這些變化帶來的風險。

3、系統(tǒng)架構(gòu)建模

有了明確的需求和設(shè)計約束之后，進入到F階段，也就是系統(tǒng)建模，針對于復雜系統(tǒng)建模，我們要考慮四個方面的問題，首先，系統(tǒng)建模的過程應該能夠展示我們是如何將我們腦子中的想法變?yōu)楫a(chǎn)品的，其次，系統(tǒng)模型應該能夠支持我們利用這些模型與我們的組織、供應商以及合作伙伴進行溝通和接洽，此外，系統(tǒng)建模工作不應該耗費工程師們大量的精力去學習一門全新的技術(shù)或知識，而是能夠讓我們在已有知識的基礎(chǔ)上簡便、快速的進行建模工作，最后我們還要能夠?qū)@些模型進行仿真，利用仿真的手段來閉環(huán)設(shè)計。

在MBSE方法中，我們用面向?qū)ο蟮?、圖形化、可視化的系統(tǒng)建模語言描述系統(tǒng)的底層元素，進而逐層向上組成集成化、具體化、可視化的系統(tǒng)架構(gòu)模型，這就是系統(tǒng)模型，它提供了有關(guān)系統(tǒng)的關(guān)鍵方面（如功能、行為、結(jié)構(gòu)、性能等）的見解，系統(tǒng)模型是系統(tǒng)開發(fā)全過程中首要的工件，我們需要對它進行管理、控制，并和產(chǎn)品生命周期的其它部分進行集成。借助相關(guān)的軟件環(huán)境及模型和數(shù)據(jù)交換標準，可以對系統(tǒng)架構(gòu)模型進行存取操作，系統(tǒng)架構(gòu)模型存儲在一個共同的數(shù)據(jù)庫中，相關(guān)參數(shù)之間就可以實現(xiàn)自動關(guān)聯(lián)；通過系統(tǒng)模型可以生成系統(tǒng)的多個視圖，比如系統(tǒng)的任務(wù)剖面、結(jié)構(gòu)圖、行為圖、接口圖等，因此，各個學科的專業(yè)工程師、各種角色，都可以基于這個系統(tǒng)架構(gòu)模型來工作，從共同的數(shù)據(jù)庫中取數(shù)、并用本學科的模型及軟件工具來進行分析。

系統(tǒng)模型作為整個產(chǎn)品研制生命周期中提供藍圖的產(chǎn)品體系結(jié)構(gòu)，對實現(xiàn)多學科、多領(lǐng)域、跨部門的高效協(xié)同起著至關(guān)重要的作用，正如沒有一套指導下游行業(yè)的藍圖，你就不可能啟動一個建筑項目一樣；沒有一個指導詳細設(shè)計的產(chǎn)品架構(gòu)，你就不應該啟動一個復雜的/多領(lǐng)域的產(chǎn)品開發(fā)工作。在西門子iMBSE解決方案中，系統(tǒng)模型不是一個孤島，而是一個協(xié)同中心。

1、系統(tǒng)模型要與客戶需求建立追溯關(guān)系，確保架構(gòu)方案滿足客戶要求；

2、能夠基于系統(tǒng)模型自動生成系統(tǒng)文檔和規(guī)范，支持基于模型的評審；

3、系統(tǒng)模型要與仿真分析模型形成閉環(huán)，確保設(shè)計方案正確，能夠交付正確的產(chǎn)品；

4、機械、電氣、軟件、六性等各領(lǐng)域?qū)W科的設(shè)計起點，要以系統(tǒng)模型為頂層設(shè)計框架，實現(xiàn)基于模型的、跨部門的高效且有效的協(xié)同。

系統(tǒng)建模的核心要素就是語言、方法和工具，建模語言作為各個學科團隊之間溝通的橋梁，它定義了建模的語法和語義，比如我們常用的就是SysML\UML建模語言，方法定義了建模的步驟，比如Arcadia方法、Magicgrid方法、Harmony-SE方法等，工具就是用于支撐我們采用建模語言按照建模方法進行建模工作的軟件產(chǎn)品，比如Capella、Catia Magic、Rhapsody等。

圖4. DSML語言中的各類視圖

在西門子MBSE解決方案中當中，我們采用的是DSML領(lǐng)域建模語言，它起源與法國泰雷茲公司，當初是為了解決SysML和UML語言復雜，學習難度高，建模難度大的問題，從而將UML和SysML進行了封裝并借鑒了一部分UAF的思想所開發(fā)出來的一款專門在工業(yè)領(lǐng)域進行系統(tǒng)工程落地的語言，值得注意的是，DSML語言并不是一款全新的語言，它只是SysML的另一種表現(xiàn)形式，它依舊滿足SysML的標準，可以與SysML的模型進行互操作，與系統(tǒng)工程緊密結(jié)合，相較于SysML而言，極大的降低了建模難度，更易于被系統(tǒng)工程師所接受，與SysML相似，DSML也從行為和結(jié)構(gòu)兩個方面來分別描述系統(tǒng)的活動和組成，包括活動圖、時序圖、功能流圖、BDD圖等。

圖5. Arcadia方法論

同樣，Arcadia也是起源于法國泰雷茲公司，Arcadia是一種基于模型的方法，致力于系統(tǒng)、軟件和硬件架構(gòu)工程。它描述了理解和捕獲客戶需求、定義和在所有工程利益攸關(guān)者之間共享產(chǎn)品架構(gòu)、早期驗證其設(shè)計并證明其合理性的詳細推理過程。

Arcadia方法高度依賴于功能分析，這是系統(tǒng)工程師中非常流行的技術(shù)。Arcadia實施了一種基于不同工程視角的方法，在系統(tǒng)上下文和需求建模（運行需求分析和系統(tǒng)需求分析）和解決方案建模（邏輯和物理架構(gòu)）之間建立了清晰的分離。它包括問題域和解決方案域兩個層面，首先是問題域，此時將系統(tǒng)看成黑盒，主要分析系統(tǒng)提供的外部功能和接口，在操作性分析階段，主要分析系統(tǒng)的運行環(huán)境，定義系統(tǒng)的運行能力、相關(guān)參與者以及活動，接下來進行系統(tǒng)分析，確定系統(tǒng)的邊界，定義系統(tǒng)為了滿足運行能力所需的功能和功能之間的交互關(guān)系，從而得到系統(tǒng)的功能需求和相關(guān)接口；得到功能和接口需求之后，進入到解決方案域，此時將系統(tǒng)打開，作為白盒，主要分析系統(tǒng)的內(nèi)部結(jié)構(gòu)、子系統(tǒng)組成及各子系統(tǒng)之間的接口關(guān)系，首先要定義系統(tǒng)的邏輯架構(gòu)，將系統(tǒng)的功能分配到各個邏輯子系統(tǒng)，此時可以采用架構(gòu)創(chuàng)成和選優(yōu)的方法執(zhí)行第一輪次的架構(gòu)權(quán)衡，以獲得滿足期望的最優(yōu)的產(chǎn)品邏輯架構(gòu)，接下來進行物理架構(gòu)，定義系統(tǒng)的物理組成，同一個邏輯架構(gòu)可能有不同的物理解決方案，所以此時需要進行第二輪的架構(gòu)權(quán)衡，來獲得即滿足需求同時又性能最優(yōu)的物理架構(gòu)方案，最終，我們基于物理架構(gòu)方案形成終端產(chǎn)品的分解結(jié)構(gòu)，也就是EPBS，確定產(chǎn)品的最終物理構(gòu)型。

Capella在航空航天、軌道交通、核能、防務(wù)等行業(yè)都得到了廣泛的應用。比如羅羅公司使用Capella對他們的渦扇發(fā)動機動力變速箱的潤滑油系統(tǒng)進行建模，他們認為Capella的系統(tǒng)到子系統(tǒng)轉(zhuǎn)換功能很好的支持了不同團隊之間基于模型的協(xié)作，同時相比于UML/SysML受復合關(guān)聯(lián)原則的約束，Capella無約束的功能和系統(tǒng)建模，完全滿足他們對于具有大量交互和涌現(xiàn)行為的大型復雜系統(tǒng)的建模場景。除此之外，阿麗亞娜集團采用Capella在運載火箭和戰(zhàn)略導彈的發(fā)射系統(tǒng)上進行了應用，大陸集團使用Capella推動智能交通系統(tǒng)的研發(fā)。

圖6. 西門子系統(tǒng)建模工作臺（SMW）

西門子系統(tǒng)建模工作臺（SMW）是在Capella的基礎(chǔ)上，新增了與Sysml模型互換的功能并集成在Teamcenter上的一款系統(tǒng)建模工具，通過將Capella集成到TC中，借助TC數(shù)字線程的能力，能夠?qū)崿F(xiàn)從需求到系統(tǒng)建模、仿真以及專業(yè)設(shè)計之間數(shù)據(jù)的無縫傳遞，構(gòu)成平臺級MBSE解決方案，同時將系統(tǒng)模型連接到產(chǎn)品生命周期中，能夠?qū)崿F(xiàn)基于模型的協(xié)同和系統(tǒng)模型的生命周期管理等價值，除此之外，SMW也與其他的需求管理工具提供接口，實現(xiàn)需求與系統(tǒng)模型之間的數(shù)據(jù)同步。

4、系統(tǒng)架構(gòu)創(chuàng)成及優(yōu)選

在基于模型的系統(tǒng)工程正向設(shè)計過程中，系統(tǒng)架構(gòu)設(shè)計是最重要的環(huán)節(jié)。系統(tǒng)在需求確定后，就可以開始系統(tǒng)架構(gòu)設(shè)計的工作，架構(gòu)設(shè)計主要探討和研究系統(tǒng)的核心和內(nèi)在，也就是系統(tǒng)的功能及其實現(xiàn)。

創(chuàng)成式工程或創(chuàng)成式設(shè)計（Generative Engineering、Generative Design）是一個創(chuàng)新的架構(gòu)設(shè)計過程。創(chuàng)成式工程在給定一些約束條件下，根據(jù)設(shè)計者的設(shè)計意圖，通過創(chuàng)成式設(shè)計來產(chǎn)生多種可能的可行性架構(gòu)設(shè)計方案，然后通過機器推理技術(shù)（Machine Reasoning）或其他技術(shù)進行綜合對比，通過設(shè)計者進行最后的決策并篩選出最優(yōu)設(shè)計方案。

復雜系統(tǒng)的設(shè)計過程我們也可以稱為創(chuàng)造或創(chuàng)新過程，因為設(shè)計過程需要極強的創(chuàng)造力，而創(chuàng)成式工程在系統(tǒng)架構(gòu)設(shè)計過程中，完全可以幫助企業(yè)通過創(chuàng)成和驗證滿足需求的創(chuàng)新解決方案來有效地進行設(shè)計空間的探索，利用算法和基于知識的推理方法來自動生成選項，并且協(xié)助用戶向下選擇替代方案并驗證最佳概念和設(shè)計，也就是說創(chuàng)成式工程旨在支持從產(chǎn)品創(chuàng)意到最終產(chǎn)品的工作流程。

當前我們的系統(tǒng)或領(lǐng)域架構(gòu)設(shè)計，都是依賴于設(shè)計師的經(jīng)驗或參考以往的數(shù)據(jù)來定義，那么對于沒有經(jīng)驗的工程師或者對于一個沒有參考的創(chuàng)新性產(chǎn)品而言，我們?nèi)绾慰焖俚纳蓾M足需求的設(shè)計方案呢？這就是架構(gòu)創(chuàng)成的范疇。架構(gòu)創(chuàng)成實際上是一種范式轉(zhuǎn)變，它是利用仿真和人工智能驅(qū)動的手段，自動生成系統(tǒng)或各領(lǐng)域的架構(gòu)方案，從而進行快速的方案設(shè)計和創(chuàng)新.

在產(chǎn)品概念設(shè)計階段，工程師通常根據(jù)直覺或以往設(shè)計經(jīng)驗進行總體架構(gòu)方案設(shè)計和整體性能指標決策，這將導致設(shè)計固化從而限制架構(gòu)方案的創(chuàng)新和尋求最優(yōu)方案的可能性，整體性能參數(shù)被設(shè)定后由下游開發(fā)團隊進行子系統(tǒng)性能標定，隨著越來越多的關(guān)鍵指標的確定，設(shè)計固化的問題也越來越明顯，一旦一種或局限的幾種架構(gòu)方案被設(shè)定，我們可以通過仿真進行設(shè)計優(yōu)化，但此時已為時已晚，我們無法獲悉是否存在更好的架構(gòu)方案。

Simcenter Studio 是Simcenter 產(chǎn)品組合中的一個應用，用于在早期概念階段生成和評估系統(tǒng)架構(gòu)。該軟件包含有專利技術(shù)，以便使工程師和數(shù)據(jù)科學家創(chuàng)建新穎的、拓撲上不同的系統(tǒng)架構(gòu)。Simcenter Studio 還將系統(tǒng)仿真、最優(yōu)控制方法、以及建立在最先進的機器學習和科學計算堆棧之上強化學習合并在一起，以便對數(shù)百種此類架構(gòu)進行自動仿真和評估。這種方法允許工程師和數(shù)據(jù)科學家在計算筆記本中創(chuàng)建用戶定義的程序，用于創(chuàng)成式工程。

圖7. Simcenter Studio架構(gòu)創(chuàng)成工作和評估流

Simcenter Studio 可以基于用戶定義的系統(tǒng)組成、接口數(shù)量與類型等生產(chǎn)各種可能的系統(tǒng)架構(gòu)和配置方案，Simcenter Studio與 Amesim 聯(lián)合仿真獲得各個需要評估的性能參數(shù)。Studio 將Amesim中的仿真結(jié)果存儲于HDF5文件中，同時對結(jié)果數(shù)據(jù)進行后處理并可視化，形成包含了所有的架構(gòu)、不同架構(gòu)各參數(shù)分部圖、各種性能的統(tǒng)計結(jié)果，我們通過性能的選擇，可以獲得滿足要求的系統(tǒng)架構(gòu)。

圖8. 汽車傳動系統(tǒng)可能的架構(gòu)數(shù)量

以混動汽車為例，基于Simcenter Studio進行架構(gòu)創(chuàng)成設(shè)計，首先基于功能分析建立ICE、Battery、Motor、Generator、Gearbox、Torque Coupler、Axles與Vehicle；并且Axles分為前軸Frontaxle、后軸Rearaxle，而前、后軸又具有各自的軸系Frontaxle_indlv 與 Realaxle_indiv與前后軸差動器Frontaxle_diff與Rearaxle_diff。

圖9. 在Simcenter Studio中定義的HEV系統(tǒng)組成

Simcenter Studio中可以對組件的數(shù)量進行控制，例如我們可以選擇1個、2個、3個或4個電機對汽車進行驅(qū)動，采用0或者1個齒輪箱來構(gòu)建系統(tǒng)。根據(jù)工程經(jīng)驗，可以設(shè)置某個接口必須與另外一個接口相連接或無法連接的限制連接或者指定連接條件，從而生成符合要求的系統(tǒng)架構(gòu)。同時，Simcenter Studio可以設(shè)置各個組件的變體參數(shù)，例如發(fā)動機排量為1.5L或2.0L，電動機功率和扭矩為96Kw，250Nm或50Kw，200Nm等。

圖10. 在Simcenter Studio中對組件數(shù)量、接口數(shù)量、類型與物理量的定義

基于上面設(shè)置的限制條件與組成設(shè)置、接口設(shè)置要求Simcenter Studio基于AI技術(shù)最終可以自動生成滿足條件的所有系統(tǒng)架構(gòu)和配置方案。

圖11. Simcenter Studio自動生成26種拓撲架構(gòu)和1566種配置方案

Studio通過調(diào)用Amesim仿真計算可以獲得各種架構(gòu)和配置方案下混動汽車百公里加速時間，這是汽車動力性能評估主要的指標之一。Studio生成除了百公里加速外，其他如油耗、里程等方面的計算結(jié)果，結(jié)果中包含了所有的架構(gòu)、不同架構(gòu)各參數(shù)分部圖、各種性能的柱狀統(tǒng)計結(jié)果，我們通過性能的選擇，可以獲得滿足要求的系統(tǒng)架構(gòu)。

圖12. 不同架構(gòu)所獲得的百公里加速時間及油耗結(jié)果

工程師須對各類架構(gòu)方案和配置進行快速篩選，并選定其設(shè)計參數(shù)，設(shè)計過程需盡可能實現(xiàn)多方面的平衡。工程師在Simcenter Studio中對生成的架構(gòu)和配置方案進行帕累托尋優(yōu)，選定的架構(gòu)和配置方案相比于以往憑直覺或經(jīng)驗選定的方案，電池容量增加44%，綜合油耗降低20%，成本及加速時間均有下降。

圖13. 在Simcenter Studio中進行多屬性平衡，快速篩選最優(yōu)方案

5、總結(jié)

圖14. 西門子概念階段MBSE解決方案流程

通過西門子概念設(shè)計階段MBSE解決方案，我們實現(xiàn)了以需求為驅(qū)動的設(shè)計仿真閉環(huán)場景，將需求管理與系統(tǒng)建模相結(jié)合形成了需求驅(qū)動的Z字型設(shè)計流程，任務(wù)需要作為系統(tǒng)建模的輸入進行運行分析可形成利益攸關(guān)者需求，同時利益攸關(guān)者需求又作為系統(tǒng)功能分析的輸入得到系統(tǒng)需求，通過邏輯架構(gòu)定義可以將系統(tǒng)需求分解并分配到子系統(tǒng)，最終指導系統(tǒng)物理架構(gòu)定義，形成軟硬件需求；除此之外，在進行邏輯架構(gòu)定義和物理架構(gòu)定義的過程中，我們都可以采用創(chuàng)成式工程進行架構(gòu)的創(chuàng)成和擇優(yōu)，同時在邏輯架構(gòu)和物理架構(gòu)權(quán)衡過程中，我們可將相關(guān)架構(gòu)模型導出為系統(tǒng)仿真架構(gòu)，通過調(diào)用Amesim中的仿真模型，進行架構(gòu)方案的權(quán)衡和驗證。