SOA汽車軟件開發和部署步驟及接口描述語言轉換方案

SOA架構盛行

隨著汽車新四化的推進，汽車整車廠在實現車輛網聯、自動駕駛和數據驅動的同時，更要在滿足用戶體驗和基本服務的基礎上快速響應客戶的個性化需求，為更好地解決這些新的挑戰，整車廠引入了高性能的芯片、突破性的技術產品，同時傳統的EE架構也需要變革，SOA（面向服務的架構）成為大多整車廠響應市場需求的首選架構。SOA架構的主要優勢是可以在很大程度上實現分布式系統軟件模塊間的解耦，通過軟件升級OTA可以更方便靈活地將服務實體部署在任意的域控制器上，服務之間只需通過簡單、精確定義的接口進行通訊，不涉及底層編程接口和通訊模型。而且對于ECU的版本更新、信號庫更新、代碼修改等過程更加簡便和靈活。簡化了注冊服務與調用API，節約了時間成本，提高系統的健壯性和擴展性。 ? ? ? ? ?

SOA開發和部署步驟

設計和部署一個SOA汽車軟件大概可分為以下幾個步驟: ?

圖1? SOA開發部署步驟

服務接口開發階段往往需要挑選有固定規則、邏輯性強，又有大量高度重復的場景進行測試驗證，為了快速進行驗證，架構工程師通常會以IDL(接口描述語言)來做服務定義描述，作為開發鏈路上后續工作開展的輸入，業務邏輯開發階段以統一的標準進行服務實現。 ? 市面上的IDL語言非常多，例如FIDL、Protobuf、vCDL、ARXML、OMG IDL、CANoe FDX等。測試人員對于各種IDL的語法規則需要零基礎開始學習，在轉換過程中相應的操作也比較復雜、繁瑣，同時出錯率也很高。 ? 如果軟件的架構采用了SOA，對系統中的功能進行了服務化，在前期技術選型，清單定義、架構設計以及中期的業務邏輯開發階段都會碰到諸如以下的幾種場景。 ? ? ?

場景一

架構人員在使用PREEvision Adaptive AUTOSAR進行系統建模、定義服務相關SWC后，通常會導出不同類型的ARXML，該文件定義了各服務接口、數據類型、參數引用等，這些AP ARXML可導入到CANoe中進行節點仿真和監控以太網通信，也支持導入DaVinci IDE生成代碼，配合DaVinci進行開發。但是這個建模過程短期內無法完成，需要不停地溝通協調，考慮便捷性，在溝通過程中相關方會以Excel作為溝通輸入，最終會將這些Excel中的配置信息再轉換為ARXML導入到相關的工具中進行驗證。

圖2-1? 接口和數據類型定義Excel

圖2-2? 接口和數據類型定義Excel ?

如上圖簡單示例，其中結構體引用，數據類型等信息容易出錯，時常需要反復修改后再重新轉換為ARXML，這個過程費時費力，從效率角度來說也影響了軟件的開發進度。 ? ? ?

場景2

以太網測試（以SOME/IP為例）時，開發人員輸出的是Excel，測試人員需要再把Excel轉成測試軟件可以支持的文件格式，如vCDL，此環節工作量極大，正確率也無法保證。

圖3-1? 以太網測試接口定義Excel??

圖3-2? 以太網測試接口定義Excel? ? ??

場景3

開發人員在使用DaVinci做架構設計時，為了加快開發周期，通常情況下會先使用Excel做模板，在Excel中填入接口信息、數據類型、SWC定義、SWC與接口關系等信息，然后再由模塊責任人把Excel中的數據在DaVinci Developer中做相應的節點配置和連線關聯，整個過程出錯概率高并且重復性高，需要有工具能依據Excel模板文件自動生成ARXML文件，實現SWC的轉換及接口與SWC結合工作，用以提高設計效率。

場景4

在SOA架構中，中間件技術的應用使得應用軟件與底層的操作系統和硬件實現了解耦，我們可以使用 SIL （Software in loop）技術在系統開發早期對系統進行功能驗證。SIL 測試的一個重要環節是 SIL Adapter 開發。SIL Adapter 實現了測試系統對被測服務實現的調用。針對各個服務接口的 SIL Adapter代碼結構是相同的，只是接口參數數量、名稱、類型方面有少量代碼差異，整個過程重復性也較高，需要有工具能自動將架構設計產出的FIDL、XML、ARXML等文件自動轉化為C++等代碼，同時能根據文件中的描述/備注等內容自動生成插樁代碼，這將縮短驗證周期。

場景5

SOA架構設計、測試驗證等階段，工程師在使用相關工具軟件時，會使用許多配置文件作為輸入或輸出文件，但是鑒于使用的工具眾多，且文件格式之間的標準并不統一，所使用的各個開發工具及測試工具也并不能支持所有的格式，所以各個工具間的串聯并不流暢，影響工程師的工作效率，需要有工具能自動將這些不同格式的文件進行互相轉換以實現工具的高效串聯。

場景6

測試用例通常是在Doors或Polarion中管理，測試用例中的測試步驟或測試標準正常是以自然語言的方式描述，在測試執行過程中軟件無法識別這些描述性語言，測試人員需要先將這些自然語言轉換為腳本文件，再把測試腳本放到測試工程中執行，在測試用例較多的時候這個工作量將會非常龐大，需要有工具能集成相關用例管理軟件，將測試用例能自動轉換為相應的測試軟件的腳本文件，在提高效率的同時減少出錯機率。

場景7

SOA測試開發過程大體上需要進行以下幾個步驟：

1.測試規范開發：基于需求規范和測試經驗及對實現方案的理解，完成測試規范的開發。

2.SOA-HIL 測試系統需求分析和測試系統開發：被測對象的引腳和資源定義，HIL硬件及測試軟件運行環境搭建。

3.測試工程開發：開發測試工程，實現測試規范所定義的測試內容的自動化/半自動化測試。

4.仿真模型開發：開發仿真模型，與待測節點建立接口交互。

5.測試環境集成調試與測試執行：針對某一具體被測對象進行測試環境搭建、工程集成調試與測試執行。

以上各個步驟中所需的輸入物類型較多，如：SOA功能的需求規范、服務接口規范，資源定義文件，測試范圍定義，ARXML 等類型數據庫文件，測試系統第三方編程腳本，測試規范，通信數據庫，通信矩陣文件，被測節點交互數據格式定義等，需要有工具能夠按測試項目進行統一分類管理，同時能夠支持相關輸入物間進行格式轉換，轉換后的結果能夠便捷地加載到相關的測試軟件中或能夠通過網絡自動上傳到配置庫的對應位置下方便后續操作。

場景8

目前SOA架構軟件普遍采用敏捷開發方式進行管理，軟件版本的高頻迭代極大考驗了測試人員工作量和自動化測試能力，目前大多整車廠和零部件供應商基本上已在進行或正在研案持續集成測試方案來解決這一問題。

如下圖所示，隨著SOA架構的盛行，輸入物或規范文件已經出現了多樣化，但是持續集成測試推進的前提條件是需要預先將這些測試軟件不可識別的接口文件或用例文件轉換為符合測試軟件定義的規范腳本，并且能夠與相關的工具進行集成自動轉換。

圖4? 持續集成測試文件轉換需求示意圖? ? ??

為什么需要接口描述語言轉換

以上幾個場景都需要測試人員手動錄入或轉換后才能繼續推動項目進度，此環節尤為關鍵，但往往轉換周期較長，且該工作耗時又費力，出錯率也較高，導致經常返工，這些問題一直困擾著的開發/測試人員。 ? ? ? ? ? ?

PAVELINK.

SOA-Converter介紹

針對以上問題，北匯信息開發出了接口描述語言轉換工具——PAVELINK.SOA-Converter。 ? PAVELINK.SOA-Converter是一個基于Eclipse開發的IDL轉換工具。可實現對常用IDL語言的批量轉換（FIDL、OMG IDL、Protobuf、vCDL、CANoe FDX、ARXML等），例如FIDL轉CANoe FDX，FIDL與Protobuf互轉，同時也支持直接通過Protobuf轉換CANoe FDX等便捷的轉換功能，轉換前可根據用戶需求自定義輸出目錄、是否忽略注釋信息、是否批量轉換、是否轉換為多個文件等配置。 ? PAVELINK.SOA-Converter結合測試代理引擎進行自動化回歸測試，可以解決整個鏈路的溝通問題并縮短測試驗證的時間。 ? 用戶通用使用PAVELINK.SOA-Converter實現對文件的快速轉換，相較于人工轉換，不但很大程度上節約了時間成本，而且保障了轉換的正確率，提高了開發測試的進度，同時有效降低了維護的成本。 ?