基于電控框架模型的硬件資源管理研究

劉敏，李吉宗，張文學

（泛亞汽車技術中心有限公司，上海 201201）

引言

隨著汽車電器化的發展，整車上的電控系統日益增多，系統間的關聯關系也越加復雜，項目需求的不同導致開發交付物存在差異，而項目的不斷增多，車型功能的個性化配置，也使得開發交付物的重復工作不斷增加，潛在出錯概率也進一步增加。“基于模型的系統工程（MBSE）”是汽車電子研發的發展方向[1]。不同的項目必然存在部分相同的功能和車載控制器ECU（Electronic Control Unit），從而使得這些功能和零件可以應用到不同的項目中，以減少開發工作。但如何在眾多的項目和需求變更中高效地識別到這些相同點并進行沿用，同時能兼容不同項目的差異點是目前整車電控系統開發工作中的一大挑戰。因此，泛亞汽車技術中心有限公司基于Vector公司的PREEvision軟件自主創建了整車電控框架模型庫，實現不同車型項目中電控模型的復用，進而實現基于模型的整車電子架構開發。

ECU是車載電子控制功能的載體，每個ECU承載著汽車的一部分功能和算法，因此每一個ECU控制器都必須能夠提供相應的硬件資源，以確保車載軟件功能的正常運行。如果ECU控制器提供的硬件資源無法達到各個軟件組件執行的最低要求，那么將對車輛的功能產生影響，后果也將不堪設想。基于節約成本的原則，通常ECU會復用到多個項目中，如何對ECU的硬件資源進行高效準確的評估，是汽車行業的一大難點。

本文基于整車電控框架模型庫，提出一種基于模型的ECU硬件資源管理方法，以提高整車硬件架構開發效率和質量。

1 PREEvision層級介紹

德國Vector公司的PREEvision是全球應用最為廣泛的電子電氣系統（E/E）架構設計工具，其支持從電子電氣架構設計到產品系列開發的全過程，其主要包含需求設計、軟件架構設計、硬件架構設計、電氣系統和線束方案開發、拓撲結構設計等[2-4]。而且，PREEvision還具備強大的二次開發功能，提供了可以用于技術評估的算法工具，其核心的技術也是基于模型的開發，層與層之間相互滲透和映射[5]。其分層架構流程如圖1所示。

圖1 PREEvision分層架構[6]

2 汽車電子電氣架構開發

2.1 軟件架構層開發

由于需求設計層與本文闡述內容－硬件資源管理關系不大，故本文不涉及需求層設計。軟件架構用于描述系統的邏輯功能關系，即系統功能的模塊框架以及各模塊之間的接口關系，包括兩個方面的開發工作：

2.1.1 開發“功能類型”

在“功能網絡”中各模塊端口上的接口信息都需要事先在功能類型庫中定義。功能類型庫描述了所分配端口需要或提供的信息，這里的接口可近似看成技術通訊協議。在“功能網絡”建模以及對整個網絡信號進行路由規劃過程中，接口定義一致的端口之間的兼容性可以在PREEvision反映出來，如圖2所示。

圖2 軟件架構“功能類型”描述圖

2.1.2 設計“功能網絡”

“功能網絡”遵從AUTOSAR標準的定義，包括邏輯傳感器、功能塊和邏輯執行器。這些元素（也被稱為功能模塊）以層次結構的方式組織并存儲在組合模塊中。功能模塊之間通過信息交互接口進行連接。當兩個功能模塊的端口通過信息交互接口連接后，相應模塊就能進行數據和控制信息的交換。在功能網絡里，用戶可以看到各功能模塊之間的邏輯關系，如圖3所示。

圖3 軟件架構“功能網絡”描述圖

2.2 硬件系統架構開發

硬件系統架構通常在開發過程的各個階段都會被用到。在早期的設計階段，它被用于確定所有電子電器部件內部連接的最優架構方式；在設計階段，網絡圖描述了系統規范中重要的電路原理。在網絡圖中用戶可以自定義模塊及連接線的顯示方式，來凸顯與特定屬性有關聯的部件，這些屬性可以是電源供應、傳輸協議、網絡電阻等。

圖4 硬件系統架構

硬件層描述各部件之間的邏輯連接方式，例如總線系統（CAN、LIN、FlexRay、MOST、Ethernet、USB和WLAN）、傳統連接、地線和供電連接等。部件之間的所有連接通過不同的接口來實現。可將每個具體接口配置為定義了通用屬性的特定接口類型。通過網絡層的描述，可以構建部件設備內部對外連接的總體關系，如圖4所示。

上圖中包含ECU、傳感器、執行器、接地點等，同時設置連接口的類型。如圖5所示，硬件接口常用的接口類型有CAN Connector Type、CAN FD Connector Type、LIN Connector Type、Ethernet Connector Type等。

圖5 接口類型選擇

2.3 軟件層和硬件層的關系模型化

軟件層和硬件層之間通過映射和路由進行關聯。軟件層可以映射到硬件層上，代表邏輯功能通過軟件或硬件的實現方式，當軟件層各模塊之間的端口通過信息交互接口連接后，相應模塊就能進行數據和控制信息的交換。硬件層可以映射到拓撲層上，將ECU的模型與在整車的實際安裝位置關聯起來，整車總線束長度可以在拓撲層得出。

信號路由是根據映射關系按照某些規則自動建立軟件層的數據元素（Data Element）與通信層的信號（Signal）之間的映射關系。軟件層路由的目的是將軟件層的信號流映射到硬件層中的連接線上。硬件層線束路由的目的是將硬件層中的連接線映射到拓撲層中的線槽中。

圖6 模型元素的關聯關系

模型元素層級之間通過映射（Mapping）和信號路由（Routing）進行互相關聯，如圖6所示。功能需求和功能Feature是整車電子電氣開發的起點，需求層可以映射到其他層級，進行需求跟蹤，代表客戶特性通過軟件、硬件等的實現方式如需求特性根據功能劃分映射到功能框架模型，同時和系統方案相關的需求特性也可以和硬件相關的系統方案進行關聯。而軟件層功能模型可以根據架構需求映射到不同的Topo硬件ECU上，代表邏輯功能通過軟件或硬件的實現方式。當軟件層各模塊之間的端口通過信息交互接口連接后，相應模塊就能進行數據和控制信息的交換。信號路由是根據映射關系按照規則自動建立軟件層的數據元素（Data Element）與通信層的信號（Signal）之間的映射關系，并創建通信層元素，經后續集成發布相關數據庫。

通過這種模型層與層之間的關聯從而實現模型元素所有層級之間的關聯關系，形成一個完整的電控模型，而工程師只需要勾選對應的功能特征就可以在一定的規則下抽取出該功能特征對應的所有模型元素，實現了電子電氣架構的分層式及統一化開發。

3 硬件資源管理開發方法

根據上述軟硬件模型的創建方法，軟件組件已經與硬件層的ECU建立了映射關系。因此，基于整車電控系統的變體管理實現基于系統方案的硬件資源管理方案。

根據前文所述，在框架模型的建設中，每一個軟件組件都將會映射一個明確的ECU硬件（如圖7的BCM），每一個軟件組件都必須由ECU中的相對應的可執行文件來實現執行。因此，每一個軟件組件都將消耗一定的ECU硬件資源（例如ECU的RAM、ROM、CPU等資源），并且對于同一個ECU控制器，可能有一個或多個軟件組件與之建立映射關系，因此每一個ECU控制器都必須提供相應的硬件資源，如果ECU控制器提供的硬件資源無法達到各個軟件組件執行的最低要求，那么將對車輛的功能產生影響，后果將不堪設想。如果ECU控制器提供的硬件資源對于與之Mapping的軟件組件的執行綽綽有余，那么勢必造成ECU控制器硬件資源的嚴重浪費，增加了整車的研發成本和制造成本。因此，本文提出接口與硬件資源管理解決方案。基于整車電控系統變體抽取系統方案后，可以針對每一個具體的ECU，導出其需要配置的最低硬件資源管理報告，如圖7所示。

圖7 硬件資源管理方案

對于不同整車電子架構方案，同一個ECU可以映射不同的功能組件，所以工程要求的硬件資源也不一樣，因此通過映射到ECU的功能組件及接口清單即可計算出ECU的硬件資源，如表1所示。

表1 ECU 資源表

在表1中，Resource列表示硬件資源類型，Result列表示基于框架模型庫計算出來的硬件資源值，Actual列表示上汽通用汽車某實際整車項目中的ECU硬件資源。

依托整車電控系統的變體管理解決方案，工程師不僅可以方便地抽取系統方案，并且可以針對抽取的不同系統方案進行各種緯度的分析和對比，幫助工程師選擇出最優系統解決方案。針對抽取的各個不同的系統方案，對每一個系統方案中的每一個ECU硬件資源的最低要求進行分析和匯總，然后對比不同的系統方案對ECU控制器硬件資源的需求差異。由此可以幫助工程師從車輛性能與整車研發成本和制造成本等不同緯度來對抽取的不同系統方案進行分析和對比，并選擇出最優的電控系統方案。

4 總結

本文重點研究了基于PREEvision的電控模型框架庫，并基于電控框架模型庫開發了硬件資源管理方法。其中，介紹了PREEvision的各個層級（即框架模型庫的層級），并基于PREEvision，實現了軟件架構模型開發、硬件架構模型開發 及各層級之間的映射關系模型化，闡述了電控領域變體管理思想，并基于此研究了硬件的有效管理，實現每一個系統方案中的每一個ECU硬件資源最低要求的分析，可有效提高整車開發中硬件工程師的開發效率。