2022汽車半導體生態峰會演講實錄|達索系統魏周君: MBES建模的角度賦能汽車軟件開發

以“智鏈未來 本立而道生”為主題的“2022張江汽車半導體生態峰會暨全球汽車電子博覽會”由《中國汽車報》社主辦，張江高科、愛集微、浦東新區投資促進二中心承辦，11月7日-8日在上海張江科學會堂隆重舉行。

本屆峰會邀請了以半導體為核心的全球智能網聯汽車生態鏈企業高管、知名分析師與投資機構、中外行業大咖參加，瞄準新智能汽車與能源汽車技術前沿，就科創+產業+金融進行深度交流，為汽車半導體產業發展貢獻智慧和力量。同時，通過趨勢分享、前沿技術碰撞、投資邏輯解讀以及全球汽車電子博覽會，共同探討全球巨變下的汽車半導體產業鏈發展，為業界充分展示汽車電子最新發展成果與趨勢，打造國際化一流汽車半導體領域展示平臺。

其中，在11月7日舉辦的“軟件定義汽車專場”，達索析統（上海）信息技術有限公司達索系統工程高級顧問魏周君做了題為《MBES建模的角度賦能汽車軟件開發》的精彩演講，以下內容為現場演講實錄：

魏周君：大家下午好，很開心有這個機會和大家一起來做一個交流。前面也說到了，在SDV里面，我們有大的方向，我們目標客戶群體，Feature的變化，有場景的變化，座艙的變化，感知的認識，還有操作系統里面越來越復雜的操作系統的開發。在這個過程里面，方方面面都需要我們有理念的轉化。

達索析統（上海）信息技術有限公司 達索系統工程高級顧問 魏周君

今天我只講開發的方法，理念，以及我們可能用到的工具的一些變化，我不講具體的技術。

這邊我有三個議題，一是基于模型的系統工程MBSE，最近的一些發展的趨勢。

第二個方面，講一下我們在軟件定義汽車里面MBSE的一些方法、途徑。

最后說一下達索在MBSE，在SDV上的價值。

首先，我們看一下MBSE在汽車方面一些應用，現在越來越頻繁的講用戶體驗，那么車要怎么開發，以前我們可能有一個Benchmark對標，再修改它。現在用什么方法來進一步的挖掘客戶的一些新體驗或者說車要有什么樣的新特征？軟硬件怎么更好的設計滿足我們未來所謂的開放性，可迭代性等等。另外，法律法規越來越多和成本直接掛鉤。

在發展過程中，我們看到國外的廠家越來越多的注重所謂的MBSE，也就是系統架構建模在里面的應用，像雷諾，大眾，包括日系一些，還有Tier 1中的一些企業，用系統工程的方法把新的工程開發的理念引入進來。

在國內也有一些的研究機構在提，如何用新的開發理念解決相應的開發問題。

現在越來越多的研究機構，或者是國內外的一些企業都在關注這個方向。

針對SDV我們怎么用MBSE中的一些方法。這個我想和大家做一個交流，可能每個人有自己不同的一些認識。

首先我們看一下這樣一個運行的環境，我們未來的車，可能不止是一個物理的運輸工具了，更多的作為一個載體，也不再只是第三空間還是什么。交通出行系統現階段可能比天上飛的系統的復雜度要差一些。我們這個系統里面，可能要遇到一些軟件，不止有車載，還有我們的云端，可能還有每一個用戶相關的終端設備及軟件設備，這些軟件是我們要關注的點。

我們看一下這個過程里面，相應的軟件開發過程里面的復雜度越來越高。這個模型的左邊，是我們怎么定義相應的場景，這個就要影射更多的Feature出來，而這個Feature就是傳統意義上的一些Feature。也有面向我們更多的智駕出行，或者是相應的一些更廣泛應用的一些場景。

接下來的話，我們可以看到我們在系統性的設計這一塊，其實是相當欠缺的。很多我們做的事情，可能也需要有相應的功能以后，才能一步一步的再往下做。

另外在這個過程里面，我們需要去進行我們相應的26262，要做設計的追溯，再到最后的代碼，到測試，這個追溯鏈有沒有被提出來。

我們在設計的過程里面，軟件的設計，生命周期怎么管理，以及軟件和硬件的設計過程，如何進行相應協同，是我們要關注的一些問題點。

談到所謂的系統工程，我們要提一下MBSE，所謂系統工程提的是什么內容？系統工程就是跨專業協同的設計理念，我們強調不同的專業在我們設計周期里面要高效的協同起來。另外一個方面，我們要在這個過程里面，把我們系統的需求和相應的功能在早期就可以充分的考慮進來，或者是充分的分析清楚，正向的研發我們整個的設計和集成驗證的過程。

第三，我們要考慮我們整個生命周期里面的方方面面，從它的最開始的設計，到最后的運輸、交付、維護、報廢的整個過程，我們要考慮整個的運行場景，從廣度和深度的不同角度來分析它和定義它。

這三個方面，落實到我們技術或者是我們的工程技術上，就是技術的協同，全局的管控，還有一個是精細的設計，所有的過程里面的問題要盡早的歸零和測試。

第三個方面，我們要看見我們開發的技術上的一些局部的，同時要看見我們應用和場景上的整體。從這三個角度，這個就是系統工程，希望在我們的工程設計里面，能夠給大家一些另外的一個維度去思考。

我們展開來看一下這三個方面如何去落實。首先我們看一下所謂的既見局部又見整體。

現在的出行是多個系統交互的一個過程，所以我們要有相應的一些分析方法和工具幫助我們對多系統交互還有服務的層面進行相應的分析，接下來我們要定義到整車相應的結構和控制系統是什么樣。

接下來我們有整車的MDU和電子電氣的進一步設計。

再往下，延伸到我們的專業設計層面。這個過程里面，我們需要在不同的層級里面雙向可追溯，同時可以提供我們實時、透明的管理能力。另外一個方面，我們需要有自己的系統行為仿真，基于數字技術的系統行為的仿真，在早期幫助我們發現解決相應的一些在后期才會花大量的成本做的事情。

在這個過程里面提一個核心的問題，我們在這個過程里面把我們不同的利益相關者關心的問題都收集進來，用同一個模型，去做我們的核心節點，不管是從多種生產線還是多種產品線，以及特征相關的，需求相關的角度還是和我們的安全性，以及驗證相關的。還有傳統邏輯功能相關的，這些利益相關者，都整合進來，如何整合進來？這樣整合進來的優勢就是我們協作和溝通的效率大大提高。

我們現在在開發的過程里面，不停的再做這些事情，但效率似乎不高。

這個里面還有一個關鍵的點，那就是我們引入了所謂的基于模型的方法。基于模型和基于文檔的本質區別，就是我們把文檔里面零碎的信息收集到了一個完整的模型里面，這個模型會相關描述我們的需求，描述系統的構成，接口，接口之間傳輸的物質、能量、信息，以及每一個模塊具有的相應的行為，所有的這些信息都會在一個叫做系統建模語言的模型里面把它描述出來。用這個模型的語言，我們就可以方便的讓不同的專業能夠在早期進行相應的溝通，而且因為我們用的同一個模型，這個模型本身就有一致性、統一性，不是像文檔那樣你翻頁尋找。而在維護文檔的過程當中，從一個表格移到另外一個表格是非常痛苦的過程。我們要用我們的文檔，或者是用我們模型，把我們原來這些文檔的信息承載下來，加速我們的迭代，這是我們做所有工作的基礎。

這個里面我們需要建哪些模型？首先我們會建什么？這個里面有一個定義，就是基于模型的系統工程，在整個的設計過程里面需求、架構用模型來表現，同時用模型來驅動我們的分析和設計驗證的過程。

這個里面，我們做什么事情？我們對需求進行建模，這些需求變成我們的規格化，形式化，統一的管理在統一的數據庫里面。我們建立系統的模型，描述了我們系統的構成有哪些，接口有哪些，接口間的關系有哪些，以及應該具有的行為有哪些。因為我們用的是一個統一的架構模型，所以這個可以很方便的從架構模型里面提取相應信息展示給不同的業務部門的人，比如說你是關心安全性相關，你可能就可以用這個模型去生成相應的表格，幫助你做早期的分析。

在這個架構模型基礎上，我們可以添加一些相應的約束，一維的多物理場的關系，讓這個模型早期進行仿真。有了這個以后，我們可以對關鍵的參數，像續航歷程，扭矩，ADAS的一些碰撞的時間，可以進行早期的虛擬化仿真。這個基礎上，我們優化性能。

有了這個模型，接下來就可以讓它細化，進一步的在其他的專業上面做一些設計，變成我們自己詳細的規則。

這個模型，或者是系統工程，并不是專門做某一件事情，而是起到粘合劑的作用，把所有的相關的工程結合到一起，發揮1+1大于2的效果，這個是我們需要建立的一些模型，我們有需求、架構、分析、協同相關的模型等等。

我們看有什么樣的應用？首先就是這個架構模型里面，你可以看到我們的架構模型，描述的就是我們的系統以及系統的上下文和系統的相應元素。它描述的角度是我們不同的利益相關者關心的一些問題，通過不同的架構視角表現出來，同時架構里面又包含了相應的對這個架構需要滿足的一些約束，和最后設計過程里面設計的決策，都會描述在里面。

具體來看，我們看到這個里面是我們一個相應的建模方法論，這個由我們的相應模型產生。根據這個模型的方法論，一步一步的產生模型。之后會得到相應的需求模型，描述需求，以及需求之間的一些約束。

接下來，我們描述系統的相應組成，以及接口。進一步把我們的組成和約束變成甬道圖，承載我們的功能，以及他們之間的交互。

下面我們進一步的描述是我們每一個板塊里面具有的行為，以及狀態的切換等等這些信息。所有這些信息，是在同一模型里面，只不過用視圖的方法把這些東西展示出來，這些都是車載的空調系統不同的表現而已，最后這些信息可以用文檔生成的形式打印出報告。

下面我們可能會設計某一個詳細的模型，需要多個模塊用不同的協議來傳遞，我們的模型同樣也是可以描述協議這個層面。剛剛說到兩個模塊之間，有各種形式。我們用模型的方式，把我們的協議描述出來，比如DDS里面用哪些定義者，哪些發布者，相應的數據類型等等。這些描述出來的協議，我可以進一步的把它導入到后面的RTI的框架里面生成代碼，我們的設計，可能是一個ADAS系統，我們最開始是設計相應的一些用例，有一些功能我們用DDS的方法實現出來。我們建這些模型，最后可以導出到軟件的框架，生成相應的代碼。

我們剛剛說到我們進行協議層面的一些實現，另外一個方面就是可以在早期用模型的方法來優化整個算法。這個例子里面，也是用建模的方法論，實現一個道路保持最早期的狀態期（音）。用這個狀態期（音），我們驅動虛擬的車輛在早期進行道路保持算法的驗證。

這個車輛有完整的動力模型，感知的模型，這個模型里面把算法添加進去就可以進行早期驗證。

這個是我們運行的一個架構控制的狀態機（音），是我們的整個測試的虛擬平臺，它可能會在整個的算法過程里面進行道路保持和跟車。

這個是我們在早期對道路保持算法的狀態機（音）的定義。這個是虛擬的駕駛的場景，有車道線檢測，以及對車道居中的算法，要跟車，跟隨前車的速度。我們會把方向盤打一下，它會根據算法達到我們要達到的目的。我們可以用工具實現動力學、感知的模型。算法的模型可以在這添加進去，這個狀態機（音）可以導入到C苗L你可四（英音），里面可以進一步的系，生成代碼，進行后續的開發。我們早期可以幫助你實現這個能力。

從這一步生成代碼，大家覺得沒有什么意義，你要想一下，我們這個狀態機模型，在早期的時候和其他的算法模型，或者是其他的中控的一些模型，很多的狀態機要聯合仿真的時候，它的意義就產生了。因為多個算法交互到一起，它們之間的行為的表現會不會是你預期這個樣子？如果用想象的方式，可能是不容易驗證的。

接下來，我們在這里也有相應的東西。同樣是虛擬的道路、傳感器，在這個過程里面我們用一些感知的方式，把信息傳輸到算法模型里面，剛剛的狀態機的模型存在Similar Linux，我們在里面進行一些開發，把這個里面的模型和虛擬的空間里面的這一輛車結合起來，然后進一步的驗證更復雜場景里面一些表現。

在這個過程里面，可以給座艙加上一些捕獲眼動，頭動的能力，可以更方便的顯示，比如說有一個操作臺，我們加上VR的眼鏡，可以在這個里面顯示或者是模擬有人，無人操作的情況下我們這個ADAS的系統和駕駛人員的整個體驗情況。

這邊有一個視頻，我不具體的放了。這個描述的就是虛擬的場景如何與Similar Linux進行聯合仿真的能力。

接下來我們看一下，我們剛剛說的建立模型，一層一層的建立，讓這些模型牽引我們的工作的意義是什么。我們在統一的一個數據源下面，把我們所說RFLP，需求、邏輯、功能的模型串聯到一起，支撐著這個過程里面所有的業務操作。包括相應的需求的開發，或者是整車的架構設計，電子電氣的架構設計，軟件架構的設計，讓我們用一套模型牽引整個設計。同時借用已有的一些工程管理，方便我們在這個過程當中的管理。

最后一個方面，說到我們所謂的多個專業的協同。這里提到一個關鍵的問題，不管是26262還是什么，提到端到端的追溯。我們想做到的追溯就是從我們前端，可能用多種工具已有的需求，到我們過程當中涉及到的需求、功能，邏輯組成的實現，包括物理的實現。以及我們最后的相應代碼、模型如何在這個過程里面有效的整合到一起。我們也有一個視頻。

這一塊我們有一個端到端的追溯，可以從不同層級的需求，追溯到我們的Similar Linux模型，追溯到我們的電子電氣的架構，追溯到我們的每一個代碼，以及相應的測試，整個追溯鏈可以完整的拉通出來。

我們提供一個環境，支持這種完整的車載軟件的全生命周期的覆蓋，這里就和我們的SPACE有一個影射。我們在這個環境里面有支持軟件相關的工程，有我們規定的一些系統架構的問題。還有系統層級關心的流程，還有軟件面的一些流程，都會在這個環境里面來支持。

我們在這個里面把我們所有的軟件的交付物和我們硬件的交付物，結構件的交付物整合在一起，實現我們面向采購，供應的一些完整的管理。

我們通過其他一些手段，實現我們相當于OTA的同步，你可以通過OTA的服務器往后端傳輸。

我們把前端的SPACE要求的系統層面，軟件層面的設計，我們整車的管理和OTA進行結合。

這個過程里面，幫助我們進行一個全生命周期的持續集成管理。

同時你可以看到，兩個環境里面，他們負責的范圍不一樣，我們整車的集成環境里面，負責整車的相應架構、問題，還有一些電子電氣的架構的一些設計問題。另外一個方面，我們軟件相關的快速迭代環境，我們可能關注軟件相應開發的管理流程，以及相應的變更、CRCD過程，和我們開發人員必須去操作的一些開發工具他們之間的關聯關系。

同時在這個過程里面，我們也是有比較完整的管理鏈，我們實現了所謂的LM IN PRM（音）的過程，這個過程可以實現軟件的開發，快速的迭代，我們可以把我們軟件開發的交付物和整車開發的交付物結合起來，不會出現以前軟件和整車產生比較大的割裂情況。

因為在未來的情況下，可能軟件要和我們的硬件，和我們的結構結合。不管是座艙，還是智駕，整個架構的一些選用也有一個快速迭代的過程，我們要用一種更好的方法把整個的糅合到一起。

最后看一下我們達索對軟件定義汽車在MBSE上面的策略和價值。核心的點就是這個樣子，我們用一個達索3DE（音）的平臺，貫穿架構建模的過程。同時讓我們在這個過程里面定義的這些模型，不管是需求，功能，邏輯相關，還是和交付物相關，都可以有聯系性。和我們外部的一些業界標準、工具有一個開放性的接口，這個是我們達索對如何在軟件定義汽車上面用MBSE的一些核心的理念。

落實下來，主要就是分三個方面，我們定義為一個多尺度的架構建模，這個從我們的整個場景的定義，再到特征的定義，再到功能，用例，到最后的實現，我們通過不同尺度的架構建模的工具和方法，幫助我們實現。

另外一個方面，我們所說的這種多專業的協同設計，用模型牽引不同的專業，實現他們的追溯性，協同的關系。

還有就是提供更多的虛擬仿真的方法，讓我們在微模型末端要做的事情，盡早在早期得到權衡驗證。

這個里面概括就是我們的架構建模，有我們需求和系統的建構，多專業的協同里面有不同的視角模型，以及我們從架構模型到不同專業模型當中的一個下發或者是聯動，還有一個方面是提供我們一些分析的模型，幫助我們進行指標的分析和性能的評估。

像這個圖里面，這個是我們的傳統的V Model，我們以前很多的東西都在后面做，前面的迭代利用的是大量瀑布式的基于文檔的方式，我們基于模型的方式給我們的好處就是，在前期能夠在每一個階段用我們的模型，加速我們的分析。另外一個方面就是把我們以前在V Model后面做的事情提早到V Model的早期進行，再進行早期的權衡驗證。

這個是我們達索的MBSE應用到SDV一些價值，簡單的來說就是首先我們構筑的是一個正向開發的能力，我們會描述我們各個階段需要不同的模型。下面我們構筑面向于智能網聯汽車的一個架構設計的能力，在這個里面，可能有我們不同的、基于特征的產品線的分析。還有我們相應的不同層級的軟件開發的過程，以及我們軟件的一些早期的定義和仿真的能力。

最后，也是比較重要的一點，還是想通過另外一種不同的設計方式實現。因為這個基于模型的設計有一些特有的價值，也就是說我們能夠用模型把我們以前用文檔寫出來的模式記載下來，加速迭代。

另一方面，我們以后的這種產品可能都是一些高度智能化的產品，它本身需要我們用一些不同的方式來表現，我們現在做的很多的東西，可能是人寫的文檔，可能是一個表格，沒有意義。我們用模型承載下來以后，每一個表格的信息有語法語義，背景關系，這樣有利于我們以后面向更復雜的系統，或者是復雜度超過我們以前機電系統若干倍的開發過程里面，更好體現我們工程師的創造能力。這個是我今天要分享的，謝謝大家。

（注：以上速記內容未經本人確認）