基于PREEvision和MATLAB開發AUTOSAR軟件組件方法及實踐

2025-03-17 00:00:00李長洲陳興李超高仕寧王長樂曾志豪

汽車文摘 2025年3期

【歡迎引用】李長洲，陳興，李超，等. 基于PREEvision和MATLAB開發AUTOSAR軟件組件方法及實踐[J]. 汽車文摘，2025（XX）： X-XX.

【Cite this paper】 LI C Z，CHEN X，LI C. Method and Practice of Developing AUTOSAR Software Components Based on PREEvision and MATLAB[J]. Automotive Digest （Chinese）， 2025（XX）： X-XX.

【摘要】隨著整車電子電氣架構的不斷演進，集中式面向服務的架構（SOA）逐漸成為電子電氣架構開發的主流方向。為了探究SOA架構開發方法及流程，通過方法研究、流程分析及開發實踐，提出一種面向服務的架構框架下軟件組件的開發方法，分析了符合AUTOSAR規范的軟件組件開發流程?；谔岢龅姆椒傲鞒探o出了從需求分析、服務設計、架構設計、應用開發、軟件集成與測試的開發實踐。通過應用證明了該開發方法有助于主機廠更高效地實現軟件模塊的集成和復用，具備很好的迭代和擴展性。

關鍵詞：面向服務的架構；PREEvision；MATLAB；軟件組件；軟件架構

中圖分類號：U463.61 " 文獻標志碼：A "DOI： 10.19822/j.cnki.1671-6329.20240177

Method and Practice of Developing AUTOSAR Software Components Based on PREEvision and MATLAB

Li Changzhou， Chen Xing，Li Chao，Gao Shining，Wang Changle，Zeng Zhihao

（Global Ramp;D Center， China FAW Corporation Limited， Changchun 130013）

【Abstract】 With the continuous evolution of vehicle electrical and electronic architecture， centralized service-oriented architecture （SOA） has gradually become the mainstream direction of electrical and electronic architecture development. In order to explore SOA architecture development methods and processes，through method research， process analysis and development practice， a software component development method under the framework of service-oriented architecture is proposed， and the software component development process conforming to AUTOSAR specification is analyzed.Based on the proposed method and process， the development practice from requirement analysis， service design， architecture design， application development， software integration and testing is given.The application proves that this development method is helpful for Oems to realize the integration and reuse of software modules more efficiently ， with good iteration and expansibility.

Key words： Service-oriented architecture， PREEvision， MATLAB， Software component， Software architecture

0 引言

隨著汽車“新四化”（智能化、網聯化、電動化和共享化）的快速發展，智能汽車的功能愈加豐富，車輛電子控制單元（Electronic Control Unit，ECU）數量不斷增長，系統間的交互越來越龐雜，對整車電子電氣架構的要求也越來越高[1]。傳統汽車電子電氣架構開發方法大多數是基于功能的、面向信號的傳統架構，周期性發送固定信號至另一個控制器，基于靜態交互的軟件無法滿足當前快速迭代的功能需求。此外，還存在軟件模塊復用率低、與硬件存在強耦合關系、無法做到無縫移植、開發周期長以及迭代成本高等缺點[2]。在軟件定義汽車的大背景下，面向服務的架構（Service-Oriented Architecture，SOA）應運而生，其降低了模塊與模塊間、系統與系統間的耦合度[3]。軟件模塊間使用明確定義的接口進行交互、模塊組件化的方式，能夠有效降低模塊間的依賴性，延長軟件模塊生命周期，增強軟件擴展能力，提升整體的開發效率，提供了全新的汽車電子電氣架構設計路線。

在SOA轉型背景下，很多主機廠、供應商進行了SOA架構的開發探索。東風汽車技術中心提出基于模型的汽車開放系統架構（Automotive Open System Architecture，AUTOSAR）應用層軟件開發環境[4]。上汽乘用車提出一種基于PREEVision的以太網SOA設計方法[5]。東信創智科技有限公司提出一種基于PREEVision的SOA設計[6]，力爭在軟件定義汽車時代取得技術領先。

針對面向服務的架構設計方法，各傳統車企大多處于探索實踐階段，在這個過程中采用合適的方法、規范的流程、高效的工具鏈可以有效提升開發的質量與效率。本文在SOA架構框架下，探究整車AUTOSAR軟件組件的開發方法、軟件架構、開發工具及開發流程?；谕暾拈_發實踐印證了方法流程的可行性，對新一代電子電氣架構開發具有一定的借鑒意義。

1 AUTOSAR軟件組件開發方法

1.1 SOA與AUTOSAR

SOA是一種高內聚、松耦合的服務架構，服務間通過精確定義接口進行通訊，不涉及底層編程接口和通訊模型[7]。接口從產品能力（Product Capacity，PC）角度出發，采用中立的方式進行定義，其獨立于實現服務的硬件平臺、操作系統和編程語言。該構建在不同系統中的服務可以以一種統一和通用的方式進行交互，便于實現軟硬解耦[6]。上層應用開發者無須關注底層硬件架構，而專注于應用開發。

SOA的開發需以AUTOSAR平臺為依托，可擴展標記語言（AUTOSAR Extensible Markup Language，ARXML）文件是開發過程中重要的配置文件之一。將ARXML文件導入配置工具，可以實現對經典平臺（Classic Platform，CP）及自適應平臺（Adaptive Platform，AP）AUTOSAR組件軟件的設計與配置。通過結合SOA、AUTOSAR和ARXML汽車廠商可以和供應商更好地實現軟件模塊的復用和集成，SOA提供了靈活的架構，簡化了模塊之間的通訊，而AUTOSAR和ARXML則提供了標準化的參數描述和接口規范，促進了模塊間的互操性。

1.2 AUTOSAR軟件架構

AUTOSAR軟件整體框架為分層式設計，以中間件（Runtime Environment，RTE）為界，隔離上層的應用層（Application Layer）與下層的基礎軟件（Basic Software）[8]。AUTOSAR體系架構分層標準如圖1所示。

應用層軟件由1個或多個軟件組件（Software Component，SWC）實現，SWC中封裝了部分或者全部ECU功能，包括對其具體功能的實現以及接口的描述，但與ECU硬件系統沒有連接。按照整車軟件架構分層設計理論將軟件模塊劃分為車隊管理層、整車系統整體控制管理層、系統內部功能控制管理層、特定功能控制管理層、傳感器執行器控制管理以及平臺通用服務管理層[9]。按照功能域可以劃分為動力域、底盤域、車身舒適域、自動駕駛域以及信息娛樂域。不同層級、不同功能域的模塊稱為Module，可以根據模塊的實際情況劃分不同功能的軟件組件，即SWC。本文中軟件模塊分層如圖2所示。

RTE主要是為應用層提供通信手段，此處的通信是一種廣義的通信，即為接口。應用層與其他軟件的信息交互方式有應用層中的不同SWC之間的信息交互和應用層SWC與基礎軟件之間的信息交互2種形式。RTE為上述交互使用接口的集散地，其匯總了所有交互接口。不同SWC間的通信通過調用RTE提供的接口函數（Application Programming Interface，API）實現，均受RTE管理和控制。每個API遵循統一的命名規則，且僅與軟件組件自身描述有關。RTE層的軟件均由工具供應商提供的配置工具自動生成，而SWC軟件既可以通過工具生成也可以由用戶自行編寫，但要符合RTE層的API接口。

基礎軟件通?？梢詫崿FECU的基礎功能，如輸入輸出處理、數模轉換、診斷、控制器局域網通訊以及操作系統。根據不同功能，可將基礎軟件繼續劃分為4個部分，分別為服務層（Service Layer），ECU抽象層（ECU Abstract Layer），復雜驅動（Complex Driver）和微控制器抽象層（Micro-Controller Abstraction Layer，MCAL）。上述4個部分間的互相依賴程度存在差異。為了滿足不同ECU間的互操作性，基礎軟件通常借助工具自動生成。

1.3 開發工具

德國Vector公司開發的PREEvision是使用最多的電子電氣架構設計工具，可以進行不同層級的電子電氣架構設計，以ARXML通用格式的文件向下傳遞設計意圖[10]。PREEvision向開發人員提供完整的協同開發平臺，可用于基于AUTOSAR的軟件架構設計，支持SWC的創建劃分以及接口的定義設計，為軟件架構的定義和端口連接提供圖形支持，同時PREEvision還支持不同版本AUTOSAR軟件技術規范的導入導出[11-12]。使用PREEvision進行軟件建模具有以下優勢：（1）PREEvision支持AUTOSAR標準，滿足集中SOA架構項目的建設需求。（2）PREEvision能夠有效進行全鏈條追溯，若其中某一環節發生變動，PREEvision能夠展示出所有關聯變動，供開發人員參考[7]。

嵌入式軟件開發常采用MATLAB＼Simulink作為CP側開發軟件，其具備應用廣泛、易讀性強等特點。通過整合PREEVision和Simulink進行聯合開發，實現正向的、自上而下的軟件組件設計，達到快速迭代的有益效果。

在過程輔助以集成配置工具，實現軟件的底層配置與編譯。常用的工具主要包括達芬奇[13]、華為工具VOS Architect＼VOS Configurator、HIGHTEC以及Tasking。

2 AUTOSAR軟件組件開發流程

2.1 開發整體流程

AUTOSAR方法論描述了從系統需求到ECU可執行代碼產生過程的設計步驟[14]?？梢苑譃榻⒊橄笙到y需求描述、建立虛擬功能總線（Virtual Function Bus，VFB）系統描述、開發軟件組件、開發系統和子系統、開發底層軟件（Basic SoftWare，BSW）以及軟件集成6個步驟。AUTOSAR開發方法如圖3所示。

通過建立抽象系統描述，可描述為1個或多個SWC組件。通過VFB系統，將1個或多個SWC組件組合形成完整系統架構。使用支持SWC軟件開發組件的工具，根據ECU描述信息以及系統約束描述，實現軟件需求到ECU的精準映射。具體操作流程為：首先借助配置工具生成系統配置描述文件，提取各ECU相關描述，并將SWC映射至相應ECU，之后將子系統進行獨立劃分。完成上述步驟后便可針對單個ECU開展SWC與BSW的開發工作，最終將生成的代碼進行集成，生成可執行文件并下載至ECU中運行。

2.2 詳細流程

本文基于項目開發實踐，對軟件組件的詳細開發流程進行細化。開發角色主要包括設計功能設計師、物理架構設計師、軟件架構設計師、應用軟件設計師、網絡通訊設計師和平臺軟件設計師。相關角色的協作流程及交互文件如圖4所示。

3 AUTOSAR軟件組件開發實踐

基于提出的開發方法，進行了基于PREEvision和MATLAB開發AUTOSAR軟件組件的實踐，完成了CP側SOA軟件組件開發的全過程，對整車電子電氣架構正向開發具備一定借鑒作用。本文將以車輛模式模塊（Vehicle Mode Management，VMM）為例進行具體軟件組件開發實踐。

3.1 功能需求設計

車輛模式可分為基本車輛模式和特殊車輛模式2種類型。其中，基本車輛模式具有互斥性，即在特定時刻，車輛僅能處于一種基本車輛模式?；拒囕v模式包括工廠模式、存儲模式、運輸模式、展廳模式以及正常模式。特殊車輛模式可以在特定基本車輛模式下進入，且不改變基本車輛模式。特殊車輛模式當前包括遠程模式、空中下載（Over The Air，OTA）模式以及被盜追蹤模式。特殊車輛模式可以隨整車功能的豐富而拓展。車輛模式功能卡片如圖5所示。

[][功能ID F803XX 功能名稱車輛模式二級系統區域控制系統一級系統智控系統功能描述

使用場景支持車輛在制造完成后及運輸過程中部分功能需求，也用于在交付前節省電量，保證安全等用戶視角無感軟件模塊 Veh_VM_VehModMan 硬件模塊 VDC_821MCU 相關系統電源系統、網聯系統、云服務系統相關部件 VDC、CSC、ICC 體驗指標

驗收項 1、車輛模式切換

2、不同模式下的整車表現技術指標驗收項本地操作切換響應時間小于2 s 釋放日期 xxxx.xx.xx 首發車型 E00X 核心交付 PRD文檔、軟件詳細設計文檔、驗收測試報告質量要求可靠性 ]

圖5 車輛模式功能卡片

3.2 以太網服務接口設計

依據功能規范文檔的描述，按照服務列表設計模板設計以太網服務，標準服務列表中定義了符合要求的軟件組件SWC及端口和各軟件組件端口間通信所使用的接口數據類型，服務接口元素類型包括Event、Field和Method，一般Event類型用來傳輸數據，Notify和Method類型用來執行操作。

服務列表包含服務接口定義、數據類型定義、服務部署定義等信息。其中服務接口定義包含服務名稱、服務ID、版本信息、服務接口元素名稱、服務接口元素類型、服務接口元素標識符、事件組、傳輸層協議、方法參數信息、發送策略以及參考數據類型名稱[15]。數據類型定義包含數據類型名稱、數據類型類別、基礎數據類型、精度、偏移量、最小值、最大值、初始值、無效值以及枚舉值等信息。服務部署包含參與者、虛擬局域網標識符、服務名稱、服務ID、提供或者消費方服務實例標識符、端口號以及組播IP地址等信息?；谲囕v模式VMM功能規范，設計車輛模式VMM管理模塊服務列表，其中關鍵信息定義如表1所示。

完成以太網服務列表設計后，每項參數均需經過嚴格的語法、語義及格式檢查。對于服務接口數量龐大、數據結構復雜、數據類型復用的接口，人工核對將耗費大量的時間和精力，且不易發覺隱藏問題。為了應對大規模的整車工程開發，提高開發的整體效率和質量，需借助數字化的自動化校驗工具。

基于Python編程語言開發的自動化工具用戶交互界面如圖6所示。基于單點校驗規則和關聯校驗規則，可以迅速定位服務列表中設計不規范的位置，并提供修改建議，可以有效提高設計的效率與質量。條目化的校驗規則，可以根據實際的校驗需求，進行校驗規則的靈活配置，具備較高擴展性。

3.3 軟件組件建模

在PREEvision環境中開展軟件組件SWC建模工作。在測試產品線內，基于PREEvision二次開發的插件將設計好的服務列表導入。服務列表自動化導入插件如圖7所示。生成建模所需的基本元素，包括服務、服務接口、服務部署、通信接口、應用數據類型、實現數據類型以及Mapping文件。數據類型還包括計算方法（Compution Method，CM）、初始值等信息。其中Interface僅定義了通信數據的接口，對于Sender/Receiver Interface，其傳輸的數據實際在Data Element中定義。而對于Client/Server Interface，其傳輸的數據實際在方法參數中定義。數據類型由應用數據類型、實現數據類型和基礎數據類型組成。其中應用數據類型需與實現數據類型之間需建立映射關系以及轉換方法，實現數據類型需與基礎數據類型建立關聯，以確保整個建模過程中數據的準確傳遞與有效整合。建模元素的生成如圖8所示。

基于插件生成的基本建模元素，在正式產品線進行軟件組件的創建、收發接口的配置、Internal Behavior內部行為定義，關聯數據類型Mapping包等配置。最后將所創建好的軟件組件進行實例化，并完成發送與接收接口基于Interface的連線。

基于車輛硬件拓撲，建立ECU芯片，配置MAC地址、IP地址、VLAN信息以及端口等信息，完成硬件層的配置。將設計完成的軟件組件部署至硬件芯片，建立SWC至硬件芯片的映射Mapping。根據以太網通訊配置需求進行路由和通訊配置，生成通訊層System Signal、Signal Transmission、PDU Transmission等信息。完成軟件組件的軟件層、硬件層及通訊層的建模配置工作。

在SWC建模完成后，導出ARXML前可以基于PREEvision二次開發的插件，對相關參數信息進行一致性檢查。將檢查出的問題進行修正后，基于PREEvision自帶的導出功能，將SWC按照標準AUTOSAR規范ARXML標準格式導出。分別導出應用軟件層SWC的ARXML1及以硬件芯片為單位的帶軟件層及通訊層信息的ARXML2供下游開發專業配置。

3.4 軟件組件ARXML多工具復合校驗

將導出的ARXML文件基于多工具進行多維度的校驗，如圖9所示，可以通過腳本導入MATLAB生成Simulink模型，基于軟件插件AUTOSAR Component Designer工具進行檢查，檢測ARXML文件與MATLAB規則的一致性，用于適配后續的應用層軟件開發。

VOS Architect是一款軟件組件校驗和配置工具。通過圖形視圖或文本網格視圖，設計師可以檢查軟件組件，包括端口（Port）、數據類型（Data Type）、連接器（Connector）和內部行為（Internal behavior）。通過一致性檢查，可以驗證SWC設計是否符合AUTOSAR標準。導入VOS Architect工具，基于工具自帶的AUTOSAR規范檢查插件，檢查軟件集成與代碼生成的一致性問題。同時將以硬件為單位的ARXML文件導入華為VOS Configurator工具，檢查通訊層配置的報錯情況。檢查無誤后可以正式釋放，按照開發流程向下傳遞ARXML文件，用于軟件底座的開發。校驗及配置流程如圖10所示。

完成軟件組件的框架部分后，還需完善軟件組件的內部行為。一般包括RTE事件（Event）、運行實體（Runnable Entity）以及函數間變量（Inter Runnable Variable）。運行實體是軟件組件內最小的邏輯功能單元，可以被RTE事件觸發（如被定時器觸發、被接收數據觸發、被操作調用觸發）。圖10為基于VOS Architect工具進行一致性檢查與運行實體配置的過程。

3.5 應用軟件開發

應用軟件獲取到軟件架構設計釋放的標準ARXML1文件后，將配置運行實體的文件導入MATLAB，生成Simulink模型。模型的收發信息已配置完畢，應用層需進行接口的匹配與應用層邏輯的搭建?；谲浖_發需求文檔，搭建子系統內部軟件架構，劃分單功能控制模塊，進行詳細的控制邏輯開發。

以車輛模式中的OTA模式及遠程模式為例分析模式的跳轉邏輯。OTA模式進入需同時滿足以下4項條件：（1）接收到OTA業務進入OTA模式請求；（2）電源模式非Driving狀態，車輛處于靜止狀態，擋位處于P擋且以及電子手剎已施加；（3）當前未處于遠程模式；（4）當前不存在絕緣監測故障。而OTA模式在滿足以下任一條件時將退出：（1）接收到OTA業務退出OTA模式請求；（2）超時；（3）車輛下電且電源模式進入Pre-off狀態。

遠程模式的進入需同時滿足以下條件：（1）接收到遠程主控業務進入遠程模式請求；（2）電源模式非Driving狀態，車輛處于靜止狀態，擋位處于P擋且以及電子駐車制動系統（Electronic Parking Brake，EPB）已施加；（3）當前未處于OTA模式；（4）當前未處于工廠模式；（5）當前不存在絕緣監測故障。遠程模式滿足以下任一條件時將退出：（1）接收到遠程主控業務退出遠程模式請求；（2）遙控或數字鑰匙進行本地操作上電；（3）電源模式請求退出遠程模式。

基于設定功能邏輯進行應用層的軟件的詳細設計，圖11為最終完成的應用層集成控制模塊模型。

模塊開發完成后要進行系統內部測試，系統內部測試可以基于子系統模型的模型在環（Model in Loop，MIL）測試、基于代碼的代碼在環（Software in Loop，SIL）測試及基于子系統硬件的硬件在環（Hardware in Loop，HIL）測試。MIL測試過程中可以基于MATLAB自帶Simulink Test工具，創建Test Harness測試框架，基于表格設計測試用例，進行覆蓋度的測試，并生成測試報告。在測試通過后進行嵌入式代碼生成工作。將生成的代碼文件及ARXML文件釋放進行系統集成和后續的測試工作。

3.6 系統集成與測試

配置完成運行實體的ARXML文件和帶通訊層的以硬件為單位的ARXML文件可以配置硬件整體的ARXML文件，導出的ARXML文件可以用于域控底座的開發工作。

域控底座基礎軟件開發包括標準模塊配置開發、通訊服務中間件開發、復雜驅動開發、系統服務中間件開發以及平臺軟件集成。其中通訊服務中間件開發包括數據分發服務（Data Distribution Service，DDS）、面向服務的中間件（Scalable service-Oriented MiddlewarE over IP，SOME/IP）、基于以太網的診斷服（Diagnostic communication over Internet Protocol，DOIP）、CAN等。系統服務中間件包括標定、診斷、OTA、時間同步、日志管理、上網服務、系統狀態管理、內存管理、電源管理以及下線檢測等。涉及安全需求的還需進行功能安全、預期功能安全、信息安全以及操作系統安全內核的開發工作。

底座開發的每項內容均需匹配相應的測試任務，一般底座的測試項主要關注通訊測試、診斷測試、刷寫測試、資源測試、平臺功能測試；其中通訊測試包括CAN通訊、以太網通訊、標定測試、信號路由、端到端校驗；資源測試包括微控制器負載及其資源、微處理器資源測試；平臺功能測試包括Log功能測試、定時管理、時間同步、網絡管理等。經過詳細的測試的底座方可正式發版。

域控底座軟件釋放后集成經過單元測試的應用層代碼，可以進行整車級的電子電氣測試。整車電子電氣測試基于建立的統一測試場景庫，進行仿真測試、實車測試全流程測試。仿真測試包括整車代碼在環、硬件在環、整車在環測試，實車測試包括場地測試和開放路測試，支撐整車功能測試驗證。場景庫的搭建主要基于標準法規、事故場景、自然駕駛以及危險極限等，進行模型、算法、評價3個維度的測評。

代碼在環測試用于模型生成代碼和手寫算法分析，進行產品級代碼驗證。硬件在環測試是真實控制硬件在環，用于控制器算法、硬件、網絡等驗證。整車在環測試為實車在環仿真平臺，實現車輛在環測試、極限場景評價等。場地測試是實車在封閉場地、示范區及公開道路測試驗證及評價。開放路段測試是真實道路環境下的應對能力。測試項主要對功能邏輯、功能降級、報警提示、交互測試、安全測試、法規項、復雜場景測試等進行測試和評價。

4 結束語

本文提出一種面向服務的架構框架下軟件組件的開發方法，設計了符合AUTOSAR規范的軟件組件開發流程。基于提出的方法及流程給出了從需求分析、服務設計、架構設計、應用開發、軟件集成與測試的開發實踐。研究結果表明，在集中式SOA開發框架下，主機廠架構師可以在PREEvision工具中，從整車系統層面定義符合AUTOSAR規范的軟件架構，以ARXML文件的形式與下游設計軟件MATALAB、華為VOS、DaVinci等無縫對接，從而保證設計信息的準確傳遞。為了應對汽車電子功能的快速迭代，汽車制造企業可以通過這種設計方式，基于內部合理的開發流程，主導汽車從需求、設計、開發到測試的全過程，實現功能的快速實現與迭代升級，提升車型開發效率及質量。

參考文獻

[1] 李丹，呂穎，李駿，等. 面向服務的體系架構[J]. 汽車文摘， 2021（10）： 52-57.

[2] 李海明，程福明，吳文杰，等. 一種面向服務的智能駕駛系統設計方法： CN202111456035.2[P]. 2022-3-1.

[3] 王東，李井波，張晨暉，等. 一種基于SOA架構的總線系統. CN202011633659.2.[P]. 2021-5-18.

[4] 周耀，楊柳春，張凡武. 基于模型的AUTOSAR應用層軟件開發環境[J]. 2015中國汽車工程學會年會論文集， 2015（62）： 752.

[5] 宋杰靜，馬云杰，田鵬飛. 基于PREEvision的以太網SOA設計方法[J]. 2019中國汽車工程學會年會論文集， 2019（13）： 1275.

[6] 詹德凱，高越. 基于PREEvision的SOA設計[J]. 汽車實用技術， 2022， 47（23）： 62-70.

[7] 梁瑜，楊雪珠，李海霞，等. 電動助力轉向系統，車輛及電動助力轉向系統的控制方法： CN202111519164.1[P]. 2022-3-25.

[8] 孫怡琳. 基于AUTOSAR標準架構的智能遠程防盜系統設計與實現[D]. 杭州：浙江大學， 2021.

[9] 金劭男，高仕寧，李超，等. 面向SOA的E/E架構設計數智化轉型實踐[J]. 汽車文摘， 2024（3）： 31-38.

[10] 劉敏，李吉宗，張文學. 基于電控框架模型的硬件資源管理研究[J]. 汽車實用技術， 2021， 46（9）： 68-71.

[11] 王永輝. 基于PREEvision的汽車電子電氣架構設計介紹[J]. 汽車實用技術， 2019（15）： 111-112.