7月22日—23日，由蓋世汽車主辦、上海國際汽車城特別支持的“2020首屆軟件定義汽車高峰論壇”正式舉辦。本次論壇主要探討軟件定義汽車領域最新的創新理念、技術趨勢、現實挑戰等熱點話題，共謀行業未來發展之道。下面是維克多汽車技術(上海)有限公司分布式系統與網絡部門商業開發經理范科發在本次論壇上的發言：

維克多汽車技術(上海)有限公司分布式系統與網絡部門商業開發經理 范科發

大家下午好！首先感謝顧總給我留了多余的時間，因為我一直擔心我這個材料比較長一點，我們今天講了很多的趨勢，但是實實在在的我們要去落實一些事情，我相信參會的大多是開發的工程師，那軟件產品需要去設計和實現，同時要去驗證你這個產品的質量。所以我們這邊應景一下，介紹材料背景直接拿了軟件來作為我演講的開場。

我們主要去看一下怎么樣做設計以及如何去落地，以及確保質量，在軟件這一塊。我們看到整個行業在發生比較大的變化，不僅是汽車這一塊，越來越多都是以軟件為中心，所有的行業基本上軟件的價值越來越重，我們對應自動駕駛的車輛、軟件的對比越來越多。

汽車行業跟軟件相關的，基本上OEM差異化在傳感器層面，另外一塊主要差異是在應用層面，因為中間的BSP包括一些OS都是有標準化的東西我們直接去采購集成使用的。另外一個趨勢是對應軟件開發和設計越來越的被OEM控制，不一定軟件全部是由OEM去做，但是越來越多的軟件掌握的話語權以OEM為主。還有我們沃爾沃同事提到的這個部分，我們這邊對應著說供應商和OEM如何去做緊密的配合，我們對應的有持續集成、持續測試，我們越來越多會看到很多車型的功能發布和車型發布是獨立開的。

這是一個大的趨勢，我們在上午孟超總也講到了SOA對于未來來說是一個賦能者，SOA的這個技術本身對于我們未來的一些互聯也好、自動駕駛也好還是軟件更新都是一個最基本的前提，我們采用這樣的技術才能去確保我們對應的軟件能夠持續地去做相應的迭代，去滿足我們更多的一些應用。

所以這邊我們看到說，軟件很重要，然后整個開發流程上有OEM和供應商的配合以及相應的實現，我們逐一來看一下。維克多作為一家供應廠商如何去做這些，因為具體的每一項都是要去落地的。

首先來看一下服務，我相信在座的很多工程師有時候拿dbc去收發一些信號，那什么是服務？服務的載體是什么？包括我們有通訊，那通過什么方式去實現通訊的應用呢？站在OEM的角度我們會去定義各種各樣的服務，如孟總上午提到對每個傳感器和信號都進行IP化，進行相應的編碼，根據我們的應有去做相應的調用。我們能夠讓我們車里面對應的功能進行相應的升級，去滿足我們相應的應用，SOA確保了我們車與外面互聯部分能夠銜接起來。同時我們也看到了沃爾沃講到的有高性能的中央控制結點的出現。

在這張圖中可以看到我們服務有提供服務的服務方和使用者，比較有趣的是我們的服務可以放在后臺的，這是非常有趣的應用場景，我們在云端去實現相應的控制應用，但是這個里面我們去談SOA和開發的時候，非常致命的一個點就是Security，涉及所有的開發驗證工具鏈體系，每個OEM用的Security都是不一樣的，這對于供應商來說是非常嚴重的挑戰，OEM相對來說比較容易一點，因為他們是固定的一套體系，但是我們今天不會展開探討Security這個話題，我們再回到SOA主線本身上。

我們傳統所有這些車輛的設計，我們基本上都在設計的時候會定義數據庫，由哪一個ECU發布哪些信號都是固定的，在執行的時候會按照預期設定的方式進行相應的運行，我們在設計的時候系統之間都是靜態的通訊，開發通常通過C語言進行開發，在這個圖中有相應的通訊應用，但是當我們出現了服務應用的時候，服務還是應用在我們的軟件組建或者是ECU中的，我們在設計的時候是設計了一部分，但是在執行的時候其他部分也會占到相應的資源去做運算，而我們在執行的時候才會有對應的功能出現，所以整個是動態的方式去做處理，這個時候我們會通過C++去做這個事情，通常采用Adaptive AUTOSAR實現基于服務的通信，當然經典AUTOSAR平臺也支持基于服務的通信。

這是一個簡單的對比，相對來說最重要的一點，我們service-oriented這邊是動態的，這邊更多是在動態執行去做相應的實現，所以這邊我們來看一下服務到底是怎么做這個事情的，什么是service？我們對應的不同軟件組建或者ECU彼此之間相通訊我們提供的服務，服務有服務相應的接口和方法在里面，因為在座很多是工程師所以我們講技術的東西會多一點。

然后我們會把定義的service跟具體的ECU去實現服務部署的應用，我們設計的服務非常靈活的根據我們的架構設計和應用部署的對應平臺上，去實現服務之間彼此通訊的應用。所有這一切在序列化和反序列化來實現與底層通信，我們對應的是一種中間件的協議，但是跟后臺對應的時候我們慢慢看到有一系列相應的協議，這些都是中間件協議，我們需要把這個服務通過中間件協議進行序列化和反序列化的應用，才能讓服務在總線上進行相應的傳遞。我們再補充說明一點，并不是所有的服務都是通過以太網的，因為有些應用我們仍然考慮傳統的系統，SOA的需求是：傳輸速率足夠快、數據端有效數據大、支持動態通信。CAN FD這邊是可以基于AUTOSAR 4.2中定義的動態PDU，所以動態PDU也是可以實現服務通訊的，而且已有供應商有樣件證明可行。以及行業在做相應CAN下一代的總線技術CAN XL也支持基于服務通信，這是明年或者后年會發布的新的技術。也就是說車不可能所有的都用以太網，成本太貴肯定會用混合總線體系在車里面。但是我們的大基調是做服務，傳統的部分也需要去做服務去滿足我們的應用層面的需求。

我們會通過中間件實現具體服務的承載，我們會在這個里面去定義我們的service定義，我們也會去定義我們的軟件和硬件，我們會把service部署到對應的硬件上以及配置我們相對硬件信號路由等等，包括以太網的IP去實現服務的承載。這邊是我們要去根據實際車輛情況去把這樣的一個服務文件設計出來，去用作我們后面的開發工作，所以這里會導出對應的格式文件去滿足我們的應用。

另外我們這個里面要去定義相應的服務，并且也要把服務實力化，比如說服務接口、部署，包括一些狀態機的設計，這些在不同層面都是有相應的文件導出，滿足于我們后面服務的部署和設計實現。這是我們說的服務是可以去做定義實現的，維克多是一家工具供應商，我們提供PREEVision工具支持Adaptive數據庫和以太網數據庫的定義，當然也兼容傳統總線的數據庫定義。當正向開發做好數據庫是滿足我們在功能仿真、開發實現和測試驗證服務功能的基本條件。

我們需要把服務應用在具體的通訊載體以及中間件上去設計出來，然后我們才能做后續的工作，我們要去做實際，在設計好了以后我們去做一些仿真驗證我們所設計的內容是不是符合我們預期定義的，仿真了以后才能做開發實現，維克多也是一家軟件協議棧供應商，我們也可以把我們定義的相應服務進行相應的應用，我們會看到整個行業是因為車與外面的互聯接通之后，原有傳統IT很多的知識體系或者是協議等等我們會引用到車里面去，用互聯去實現。

另一塊我們車本身是非常關心安全的，我們這個行業里面有非常強的技術壁壘，比如說要去做車的診斷、整個工具鏈的打通等等這一塊，我們上下兩端都要去接通，我們去做車載高性能的計算控制器的時候，所有傳統所使用的相應的工具鏈以及我們在傳統汽車行業里面所適用的方法，就是會出現激烈的碰撞在里面，最終可能大家會走向一致。但是這個里面我仍然強調的是功能安全和信息安全，這是一定逃不開的，我們任何的駕駛都要保證可靠性的，所以我們也要考慮到如何在設計的時候實現安全和可靠性。

還有這個是大家上午講到的，娛樂系統、互聯系統以及軟件更新，這幾個大方向下去驅動我們在行業里面去做相應的應用。更細節的具體定義是在AUTOSAR里面，Adaptive AUTOSAR平臺去詳細定義。Adaptive AUTOSAR主要是對應一些模塊的API進行規范，具體怎么去實現里面并沒有做太多的說明。維克多作為協議棧供應商，積極參與規范制定過程當中去，我們也會跟我們車廠探討想法去做應用落地在控制器中。我們可以看到圖的最上面，我們有很多的APP，每個APP有具體算法實現也有OS和后臺本身的平臺調用在里面，這是我們具體的一個APP，你可以把它等價地去做類比經典AUTOSAR的SWC，但是這個有很多的復雜性在里面。當然整個系統的開發是需要一系列的工具和協議棧去做配合的，所以我們需要去做設計，包括我們有各種各樣的部署文件去設計好，我們也會結合我們自己做的一些算法邏輯和相應的協議站生成代碼，我們去做相應的工作，然后我們再編譯然后再去做部署，這是如何實現相應開發流程在里面，每個環節涉及諸多細節和工具去把整個事情做出來，先去做定義然后再去做仿真驗證，當然還有協議在里面。我們也提供相應的協議模塊，能夠去滿足我們高性能ECU平臺需要的各種各樣的場景，以及跟各種系統有相應的對接，以及對接相應的部署和承載。同時車對安全的考究是非常嚴格的，包括我們沒有做L3的時候，跟安全相關的都會要求是L4等級的，對通訊協議站也是一樣的，也要達到相應的等級才能做相應的應用在這個里面。

針對Adaptive AUTOSAR，Vector在提供協議棧的同時，也提供整個開發的全套工具鏈，我們會提供服務設計工具和診斷服務的設計工具，我們設計完了之后去得到我們所需要的產物，然后加載到我們對應的工具里面去做仿真，我們去仿真我們這個設計的理念是合理的，我們也會把相應設計的協議棧以及APP開發工具配合到一塊去做具體的實現，實現之后就要去做測試驗證，也就是下一個話題如何去做測試驗證。

測試驗證我們涉及的是SOA系統包括Adaptive AUTOSAR系統，也包括我們今天主題中的整個軟件系統如何來做驗證。在出現Adaptive AUTOSAR后驗證復雜化，我們可以看到沃爾沃的架構，它的中央控制單元，這個里面軟件系統相信不可能所有的軟件都是沃爾沃自己開發的，可能是供應商自己設計好的軟件集成到到里面的：我們會從原來的以ECU和總線為主的測試轉向以測試APP為中心，我們的功能邏輯是不是符合原來定義的，以及我們通訊的安全是不是能夠滿足我們的要求等等。對應的AUTOSAR的標準體系為我們做實驗提供了標準體系，我們在服務跟服務之間是有契約精神的，你要去測一個APP，跟它交互的APP我們要做仿真出來，以前我們做總線的時候，做一個ECU跟它交互的總下也要去做測試。因為測試有一個很基本的定律：就是盡可能早地去構建一個整車的環境，再去做相應的測試，因為跟實車越接近測試才可能更加可靠一點，對應OEM和供應商都是一樣的。

那我們要從技術層面去說明一下，我們在做SOA跟相應的Adaptive AUTOSAR系統的時候，一些基本概念我們先要說明：Communication Object和Binding。通信Object從傳統的信號演變為信號、PDU、RPC和Service。圖上這些都是我們通訊具體的載體，我們剛剛也提到了，我們單純去測APP，APP與APP之間可能有相應的交互，同時我們所設計的相應服務一些RPC我們要進行部署，我們可以非常靈活地進行部署和傳輸，下面這一層我們根據具體的協議去捆綁，我們可以換一種協議，換成Web和HTTP協議都可以應用的，有可能是單純APP測試，也可能跟協議在一塊的應用或者是仿真系統在里面。

無論是這個行業怎么發生相應的變化，基本測試我們不會有大的改變在里面，基本上都要去做比如說模型測試，代碼測試和控制器測試，這里重點說明一下代碼的這部分，今天我們不會闡述代碼本身的單元測試和集成測試。我們提的是軟件系統測試，就是沒有帶硬件板子情況下去做測試，無論是測哪一方面，我們都是要有相應的做測試本身和它交互的模型這邊實現相應的交互行為在里面，但是在測試這邊我們后面會去重點強調，我們要去改善一下到底怎么去做測試，因為我們原來的測試是文本+腳本的方式，但是現在我們比較期望采用更好的方式是模型和數據的方式來驅動我們的整個測試。

那到底怎么做這個事情呢？模型和數據是什么概念？我們后面會看到。我們在做軟件開發的時候，相應的我們的產品不可能開發一次都是沒有任何缺陷的，但是我們還需要篩選出來哪些可以做回歸，比如HiL臺架上100萬條測試用例執行后分析定位說10條是因為代碼原因引起的，當修改代碼后那如何做到代碼單元測試、代碼集成測試和系統測試？那只要去找到跟它有關聯的測試，然后用相應的方式去做，而不是像原來系統工程師一樣操作，在工具層面我們是可以解決這一問題的，當然這個也涉及到不同部門之間的銜接問題在里面，以軟件的方式去驅動定義，去做相應的測試，我們一定面臨的是如何快速地回歸測試，也是我們極大的挑戰在里面。當然Vector在這塊也提供完整的工具來解決這個問題。

已被汽車行業開發驗證廣泛使用的工具CANoe，但它依舊及其重要的。我們汽車跟IT軟件是完全不一樣的，我們汽車行業開發軟件后要做一系列的測試，每個環節全部是要做相應測試的，這里我們可以完全滿足這些測試，我們在一個工具體系里面全部做完這些事情在里面，比如CANoe支持構建MiL、SiL、HiL、DV/PV和EOL測試。同時當服務通信出現后以APP測試為主，以及CANoe這邊我們根據最近幾年的積累和跟客戶的合作，我們重新構建了軟件體系去應對我們剛才提到的軟件系統和SoA測試的問題，可以去承載相應的中間件協議，去編輯相應的解析數據信息在里面，我們對于SOA的事情還是在持續的增加功能，但是大的趨勢我們是SiL，我們肯定要去做軟件系統測試，所以CANoe未來也會在這個方面去承載我們相應的測試。我們這邊也稱之為SIL，這個跟傳統的SIL是不一樣的概念。傳統SiL測試是背靠背測試，甚至很多時候并未實際落地實施。你原來的模型跟代碼自己開發的不可能給OEM，但是我們現在是軟件系統，我們通過一些手段把算法代碼虛擬為dll，給OEM交付虛擬軟件，OEM可以在非常早期持續構建子系統和整車，所有的模塊全部是虛擬化的方式去提供出來的，作為供應商每天所開發的軟件，如果你們供應商這邊跟OEM的CI/CT環境打通的情況下，供應商每天設計的部分可以持續編譯完了以后給到OEM，OEM可以去做測試，等到我們后面有真實樣件時跟硬件無關的做回歸，有關的做增加相應的測試在里面。

CANoe4SW是Vector今年即將發布的CANoe體系中的產品。那些軟件我們是可以解決的，圖中嵌入式系統的軟件都是CANoe4SW的應用場景，我們會把軟件部署到PC端、虛擬機或者是云端。我們拿相應的工具CANoe4SW去做軟件系統功能測試，把相應的軟件分為APP端和功能接口端，功能接口端把真實ECU和API換成在虛擬環境下對應的API變量映射起來，就可以去部署一個環境，讓它運行起來。那這邊也是一樣的道理，我們能夠通過對應的技術去做這件事情，這是敏捷快速迭代的基本保障。

這邊我們能夠通過CANoe去做這樣的功能，但是如果對應的100萬測試用例拿PC順序執行，也是很費時間的，基本上不可能很快速地拿到結果，我們這邊構建技術有新的產品CANoe4Server，采用并行測試技術，按照我們的服務器來進行相應的部署，那我們這邊是對應的相應系統都可以去做支持，包括我們跟相應的交互對象可能有閉環的模型在里面，我們可以去實現部署和驗證，要能夠滿足自動駕駛的測試，或有公司真正大規模去做CI的敏捷開發測試這種方式的需求，在CANoe4Server中的配置N足夠大時，基本上幾分鐘你所有的100萬條測試用例都跑完了，所以很快能夠得到相應的結果。

針對ADAS而言，基于數據驅動的測試來驗證軟件系統是必須的。因為我們會有非常多的場景和數據去采集和產生，數據有兩個部分，一部分是來自于我們相應的仿真環節，我們產生仿真場景去做我們的仿真數據，通過并行的方式去驗證我們的軟件是否可靠，另外我們也會通過相應的設備去采集數據，把場景的數據灌到場景里面去，去驗證我們的軟件系統是否是穩定可靠的，如果我們全部是需要用數據去訓練的，那很多數據很多設備需要采集，這樣我們就能夠去部署大規模的測試系統，去驗證我們相應的系統，因為你不這么做的話，L4以上的這個成本，你要在很短的時間里面去降低成本這是不可能的，也辦不到的事情。Vector提供動力學和場景仿真工具DYNA4，同時也提供實車環境數據采集設備VX1161。

我們拿到數據要去做相應的測試，測試傳統的方法有需求和測試規范，按文本的去寫相應的腳本，然后再寫報告得到驗證。我們現在有一種新的方式，我們在傳統開發的時候基于需求去建模，在V模型的左側基于模型的方法是最好的設計理念，而不是手寫代碼。那反過來也是一樣，我們測試的輸入也是一樣的，那我們對功能測試也可以建模，因為你建模的時候變量和參數做好配置，模型也能夠生成對應的測試用例，無論是帶有狀態機的還是序列組合的方式能夠以建模的方式灌到系統里面去做大規模的測試，建模里面各方面都是可以去適用的，Vector提供測試建模工具vTESTstudio，不僅覆蓋傳統測試方式也支持全新的測試框架和技術輔助大家。

還有一個很重要的點，我們的方法會變成敏捷的方法，但是當你采用有敏捷，你搭建了持續測試的環境，如果你沒有自動化的測試腳本，你搭的環境是一個空架子。因為在中國我們很多時候會看到追風，但是你沒有足夠多的測試用力去考核你的系統，所以如果你只有按照相應的測試用例去做設計才可以達到真正的效果軟件系統的驗證。