維克多范科發：SOA設計實現與軟件系統驗證

7月22日至23日，由廣汽主辦、上海國際汽車城支持的“2020首屆軟件定義汽車高峰論壇”正式舉行。本次論壇主要探討軟件定義汽車領域的最新創新理念、技術趨勢、現實挑戰等熱點話題，共同探索行業未來發展之路。以下是維克多汽車技術（上海）有限公司分布式系統和網絡部業務開發經理范克發在本次論壇上的講話：

下午好，維克多汽車技術（上海）有限公司分布式系統和網絡部業務開發經理范克發先生！

首先，我要感謝顧先生給了我額外的時間，因為我一直擔心我的材料可能有點長。今天，我們討論了許多趨勢，但我們確實需要實施一些事情。我相信大多數與會者都是開發工程師，需要設計和實施軟件產品，同時還要驗證您的產品質量。所以，讓我們花點時間介紹一下材料的背景，并直接使用該軟件作為我演講的開始。我們將主要研究如何設計和實現，以及確保軟件方面的質量。我們看到整個行業正在發生重大變化，不僅在汽車行業，而且越來越以軟件為中心。軟件在所有行業的價值基本上都在增加，我們正在比較越來越多的自動駕駛汽車和軟件。汽車行業與軟件相關，OEM差異化主要在傳感器層面。另一個主要區別是在應用程序級別，因為中間的BSP（包括一些操作系統）是標準化的，我們直接購買并集成它們以供使用。另一個趨勢是，軟件開發和設計越來越受原始設備制造商的控制，不一定所有的軟件都由原始設備制造商完成，但越來越多的軟件由原始設備供應商主導。至于沃爾沃同事提到的部分，我們談論的是供應商和原始設備制造商如何密切合作。我們談論的是持續集成和持續測試。越來越多的時候，我們會看到很多車型的功能發布和車型發布是相互獨立的。這是一個主要趨勢。上午，孟超先生還提到SOA是未來的推動者。SOA技術本身是我們未來互聯、自動駕駛和軟件更新的基本前提。只有采用這項技術，我們才能確保我們相應的軟件能夠不斷迭代，滿足我們更多的應用。因此，在這里我們看到軟件非常重要，整個開發過程涉及原始設備制造商和供應商之間的合作，以及相應的實施。讓我們看看每一個。作為供應商，Victor是如何做這些事情的，因為每一個具體的項目都需要實施。首先，讓我們來看一下服務。我相信在場的許多工程師有時會使用DBC來發送和接收信號。那么什么是服務呢？服務的載體是什么？包括我們的通信，我們如何實現通信應用？從OEM的角度來看，我們將定義各種服務。例如，孟先生在早上提到，每個傳感器和信號都應該根據我們的需求進行IP化、相應編碼和相應調用。我們可以升級汽車內部的相應功能，以滿足我們相應的應用程序，SOA確保我們的汽車能夠與外部互連連接。同時，我們也看到了沃爾沃提到的高性能中控節點的出現。在這個圖中，我們可以看到我們的服務有服務提供商和用戶。有趣的是，我們的服務可以放在后臺，這是一個非常有趣的應用場景。我們在云中實現了相應的控制應用程序。然而，當我們談論SOA和開發時，一個非常致命的點是安全性，它涉及所有的開發和驗證工具鏈系統，每個OEM使用的安全性不同，這對供應商來說是一個非常嚴峻的挑戰。原始設備制造商相對容易，因為他們是一個固定的系統。然而，我們今天不會深入研究安全性的主題，我們將回到SOA主線本身。在所有這些車輛的傳統設計中，我們基本上在設計過程中定義了一個數據庫，哪個ECU釋放哪些信號是固定的，并在執行過程中以預期的方式運行。在設計過程中，系統之間的通信是靜態的，通常通過C語言進行開發。在這個圖中，有相應的通信應用程序，但當我們有服務應用程序時，該服務仍然應用于我們的軟件組件或ECU中。當我們設計時，我們設計了一個部分，但在執行過程中，其他部分也占用了相應的資源來進行計算，而我們在執行過程只有相應的功能。因此，整個過程是動態完成的，我們將使用C++來實現這一點，自適應AUTOSAR通常用于實現基于服務的通信，當然，經典的AUTOSAR平臺也支持基于服務的通訊。這是一個簡單的比較。相對來說，最重要的一點是，我們面向服務的一面是動態的，而我們的一面更側重于動態執行，以實現相應的實現。那里……

那么，讓我們來看看服務實際上是如何做到這一點的，什么是服務？我們提供的服務對應于不同的軟件組件或彼此通信的ECU。這些服務有相應的接口和方法，因為你們中的許多人都是工程師，所以我們將更多地討論技術。然后，我們將定義的服務與特定的ECU相結合，以實現服務部署的應用。我們設計的服務非常靈活，可以根據我們的架構設計和相應平臺上的應用程序部署進行相互通信。所有這些都是通過序列化和反序列化與底層通信來實現的。我們對應于一個中間件協議，但當我們對應于后端時，我們會逐漸看到一系列相應的協議。這些都是中間件協議，我們需要通過中間件協議應用程序序列化和反序列化此服務，以便相應地在總線上傳輸服務。我們想補充一點，并不是所有的服務都是通過以太網提供的，因為一些應用程序仍然考慮傳統系統。SOA的要求是：傳輸速率快，數據端有大量有效數據，并支持動態通信。CAN FD可以基于AUTOSAR 4.2中定義的動態PDU，因此動態PDU也可以實現服務通信，并且現有供應商的樣本已被證明是可行的。該行業正在開發相應的CAN下一代總線技術CAN XL，該技術也支持基于服務的通信。這是一項將于明年或更晚發布的新技術。也就是說，不可能所有的汽車都使用以太網，如果成本太高，肯定會在車內使用混合動力總線系統。但我們的主題是提供服務，傳統部分也需要提供服務來滿足我們的應用程序級別需求。我們將通過中間件實現特定的服務托管，在中間件中我們將定義我們的服務定義以及我們的軟件和硬件。我們將把服務部署到相應的硬件上，并配置我們的相關硬件信號路由，包括以太網IP，以實現服務托管。在這里，我們需要根據車輛的實際情況設計一個服務文件，用于我們未來的開發工作，因此我們將導出相應的格式文件，以滿足我們的應用要求。此外，我們需要定義相應的服務，并對其進行加強，例如服務接口、部署和一些狀態機的設計。這些都與不同級別的相應文件一起導出，以滿足我們未來服務的部署和設計實現。這就是我們談論的可以定義和實現的服務。Victor是一家工具供應商，我們提供PREEVision工具，支持自適應和以太網數據庫的定義，以及傳統的總線數據庫定義。在開發一個好的數據庫時，它是我們滿足功能模擬、開發實現和測試驗證服務功能的基本條件。我們需要在特定的通信運營商和中間件上設計服務，然后才能進行后續工作。我們需要做實際的工作，在設計完成后，我們需要做一些模擬來驗證我們設計的內容是否符合我們的期望。在模擬之后，我們可以繼續進行開發和實現。Victor也是一家軟件協議棧供應商，我們也可以應用我們相應定義的相應服務。我們將看到，整個行業都是由于汽車與外部世界之間的互聯互通。許多傳統IT的知識系統或協議將參考汽車，并通過互聯實現。另一方面，我們的汽車本身非常關心安全問題。我們的行業存在強大的技術壁壘，例如診斷汽車和連接整個工具鏈。我們需要把兩端連接起來。當我們去制造高性能的車載計算控制器時，傳統汽車行業使用的所有傳統工具鏈和適用的方法都是必要的，內部會發生激烈的碰撞，最終每個人都可能走向共識。但我在這方面仍然強調的是功能安全和信息安全，這是無法避免的。我們在任何駕駛中都必須確保可靠性，因此我們還需要考慮如何在設計中實現安全性和可靠性。這就是今天早上大家談論的話題。娛樂系統、互聯網系統和軟件更新正在推動我們在行業中開發相應的應用程序。更詳細的定義在AUTOSAR中，其中自適應AUTOSAR平臺pro……

des詳細定義。Adaptive AUTOSAR主要對某些模塊的API進行標準化，但對如何實現它們沒有太多解釋。作為協議棧供應商，Victor積極參與規范開發過程，我們還將與我們的汽車工廠討論在控制器中實現應用的想法。我們可以在圖的頂部看到，我們有許多應用程序，每個應用程序都有特定的算法實現，以及來自操作系統和后端本身的平臺調用。這是我們的特定應用程序，你可以等效地使用它來做類似于經典AUTOSAR的SWC，但其中涉及到很多復雜性。當然，整個系統的開發需要一系列工具和協議棧協同工作，所以我們需要設計它，包括各種部署文件。我們還將根據自己的算法邏輯和相應的協議站生成代碼。我們將做相應的工作，然后編譯和部署它。這就是如何在內部實現相應的開發過程。每個步驟都涉及許多細節和工具來完成整個事情，首先定義它，然后進行模擬驗證，當然，協議也包括在內。我們還提供相應的協議模塊，可以滿足我們高性能ECU平臺所需的各種場景，并與各種系統具有相應的接口，以及部署和托管。同時，汽車的安全要求非常嚴格，包括當我們沒有L3時，安全相關要求是L4級，通信協議站也是一樣的。在這一領域進行相應的應用之前，也有必要達到相應的水平。對于Adaptive AUTOSAR，Vector不僅提供了協議棧，還提供了整個開發的工具鏈。我們將提供服務設計工具和診斷服務設計工具。在我們設計之后，我們會得到我們需要的產品，然后將它們加載到我們相應的工具中進行模擬。我們的設計理念是合理的，我們還將集成相應設計的協議棧和APP開發工具進行具體實現。實施后，我們需要進行測試和驗證，這是如何進行測試和核實的下一個主題。在我們今天的主題中，我們參與了SOA系統的測試和驗證，包括Adaptive AUTOSAR系統，以及如何驗證整個軟件系統。自適應AUTOSAR出現后，驗證變得更加復雜。我們可以在這個系統中看到沃爾沃的架構、中央控制單元和軟件系統。據信，并不是所有的軟件都是沃爾沃自己開發的，它可能會集成到供應商設計的軟件中。我們將從最初的ECU和基于總線的測試轉向以APP為中心的測試。我們的功能邏輯是否符合原始定義，以及我們通信的安全性是否能夠滿足我們的要求等等。相應的AUTOSAR標準系統為我們提供了進行實驗的標準系統。我們在服務之間有契約精神。你需要測試一個應用程序，我們需要模擬與它交互的應用程序。過去，當我們在公交車上工作時，我們還必須測試與它交互作用的ECU。因為測試有一個非常基本的定律：它是盡早建立一個完整的車輛環境，然后進行相應的測試，因為測試離實際車輛越近，它就越可靠。相應的OEM和供應商是一樣的。因此，在研究SOA和相應的自適應AUTOSAR系統時，我們需要從技術角度解釋一些基本概念：通信對象和綁定。通信對象已經從傳統的信號發展到信號、PDU、RPC和服務。這些都是我們在圖中溝通的具體載體。我們剛剛提到，我們只測試APP，APP和我們設計的相應服務之間可能會有相應的交互。同時，我們需要部署一些RPC，我們可以靈活地部署和傳輸這些RPC。在下面的層中，我們根據特定的協議進行捆綁，我們可以切換到一個不同的協議，該協議可以應用于Web和HTTP協議。它可能是一個簡單的應用程序測試，也可能是同一協議的一部分的應用程序或模擬系統。無論行業如何發生相應的變化，我們都不會在基礎測試方面做出重大改變。我們基本上需要做一些事情，比如模型測試、代碼測試和控制器測試。在這里，我們將重點討論代碼的這一部分。今天，我們將不詳細介紹代碼本身的單元測試和集成測試。

我們指的是軟件系統……

測試，這意味著在沒有硬件板的情況下進行測試。無論我們在測試哪個方面，我們都需要有一個相應的模型來測試它本身及其交互，以實現相應的交互行為。然而，在測試中，我們會強調我們需要改進如何進行測試，因為我們最初的測試方法是文本+腳本，但現在我們希望采用更好的方法，通過模型和數據來推動我們的整個測試。我們到底怎么能做到這一點？模型和數據的概念是什么？我們稍后再看。當我們進行軟件開發時，不可能一次開發出沒有任何缺陷的產品。然而，我們仍然需要篩選出哪些回歸可以進行，例如由于代碼原因，在HiL平臺上分析和定位100萬個測試用例中的10個。修改代碼后，我們如何實現代碼單元測試、代碼集成測試和系統測試？我們可以在工具層面解決這個問題，只要我們找到與之相關的測試，然后用相應的方式來做，而不是像原來的系統工程師那樣。當然，這也涉及到不同部門之間的聯系。要以軟件的方式驅動定義并進行相應的測試，我們必須面對如何快速進行回歸測試，這對我們內部來說也是一個巨大的挑戰。當然，Vector在這方面也提供了完整的工具來解決這個問題。廣泛使用的工具CANoe已經被汽車行業開發和驗證，但它仍然非常重要。我們的汽車和IT軟件完全不同。在我們的汽車行業開發軟件后，我們需要進行一系列測試，每一步都需要進行相應的測試。在這里，我們完全可以滿足這些測試。我們在一個工具系統中完成所有這些任務，例如支持MiL、SiL、HiL、DV/PV和EOL測試構建的CANoe。同時，當服務通信出現時，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來做這樣的功能，但如果按照PC順序執行相應的100萬個測試用例，這也很耗時，而且基本上不可能快速獲得結果。我們有一款名為CANoe 4Server的新產品，它使用并行測試技術，并根據我們的服務器進行部署。因此，我們可以在我們的一端支持相應的系統，我們可能有一個帶有相應交互對象的閉環模型，我們可以部署和驗證該模型，以滿足自動駕駛測試或大規模CI敏捷開發測試的要求。當CANoe4Server中的配置N足夠大時，基本上可以運行al……

在幾分鐘內完成100萬個測試用例，因此您可以快速獲得相應的結果。對于ADAS，數據驅動測試是驗證軟件系統所必需的。因為我們有很多場景和數據要收集和生成，所以數據有兩部分。其中一部分來自我們相應的模擬過程。我們生成模擬場景來做我們的模擬數據，并通過并行方法驗證我們軟件的可靠性。此外，我們還通過相應的設備收集數據，并將場景數據注入場景。為了驗證我們的軟件系統是否穩定可靠，如果我們都需要用數據進行訓練，許多設備需要收集大量數據，因此我們可以部署大規模的測試系統來驗證我們的相應系統。如果你不這樣做，你不可能也不可能在短時間內降低L4及以上級別的成本。Vector提供了動力學和場景仿真工具DYNA4，以及實車環境數據采集設備VX1161。我們需要在獲得數據后進行相應的測試。傳統的測試方法包括需求和測試規范，根據文本編寫相應的腳本，然后編寫報告進行驗證。我們現在有了一種新的方法，在傳統開發中，我們根據需求進行建模，而V模型左側的基于模型的方法是最好的設計概念，而不是手寫代碼。反之亦然。我們測試的輸入是相同的，所以我們也可以對功能測試進行建模，因為在建模時，變量和參數配置良好，模型可以生成相應的測試用例。無論是使用狀態機還是序列組合，都可以通過建模將其注入系統中進行大規模測試。建模的各個方面都可以應用，Vector提供了一個名為VTESTstudio的測試建模工具，它不僅涵蓋了傳統的測試方法，還支持新的測試框架和技術來幫助每個人。另一個重要的觀點是，我們的方法將變得敏捷，但當您采用敏捷時，您將構建一個連續的測試環境。如果您沒有自動化的測試腳本，那么您的環境就是一個空架子。因為在中國，我們經常看到追風，但你沒有足夠的測試力量來評估你的系統。因此，如果只根據相應的測試用例進行設計，就可以達到軟件系統驗證的真正效果。

標簽：沃爾沃理念

汽車資訊熱門資訊