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

劉敏，李吉宗，張文學(xué)

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

引言

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

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

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

1 PREEvision層級介紹

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

圖1 PREEvision分層架構(gòu)[6]

2 汽車電子電氣架構(gòu)開發(fā)

2.1 軟件架構(gòu)層開發(fā)

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

2.1.1 開發(fā)“功能類型”

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

圖2 軟件架構(gòu)“功能類型”描述圖

2.1.2 設(shè)計“功能網(wǎng)絡(luò)”

“功能網(wǎng)絡(luò)”遵從AUTOSAR標(biāo)準(zhǔn)的定義，包括邏輯傳感器、功能塊和邏輯執(zhí)行器。這些元素（也被稱為功能模塊）以層次結(jié)構(gòu)的方式組織并存儲在組合模塊中。功能模塊之間通過信息交互接口進行連接。當(dāng)兩個功能模塊的端口通過信息交互接口連接后，相應(yīng)模塊就能進行數(shù)據(jù)和控制信息的交換。在功能網(wǎng)絡(luò)里，用戶可以看到各功能模塊之間的邏輯關(guān)系，如圖3所示。

圖3 軟件架構(gòu)“功能網(wǎng)絡(luò)”描述圖

2.2 硬件系統(tǒng)架構(gòu)開發(fā)

硬件系統(tǒng)架構(gòu)通常在開發(fā)過程的各個階段都會被用到。在早期的設(shè)計階段，它被用于確定所有電子電器部件內(nèi)部連接的最優(yōu)架構(gòu)方式；在設(shè)計階段，網(wǎng)絡(luò)圖描述了系統(tǒng)規(guī)范中重要的電路原理。在網(wǎng)絡(luò)圖中用戶可以自定義模塊及連接線的顯示方式，來凸顯與特定屬性有關(guān)聯(lián)的部件，這些屬性可以是電源供應(yīng)、傳輸協(xié)議、網(wǎng)絡(luò)電阻等。

圖4 硬件系統(tǒng)架構(gòu)

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

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

圖5 接口類型選擇

2.3 軟件層和硬件層的關(guān)系模型化

軟件層和硬件層之間通過映射和路由進行關(guān)聯(lián)。軟件層可以映射到硬件層上，代表邏輯功能通過軟件或硬件的實現(xiàn)方式，當(dāng)軟件層各模塊之間的端口通過信息交互接口連接后，相應(yīng)模塊就能進行數(shù)據(jù)和控制信息的交換。硬件層可以映射到拓?fù)鋵由?，將ECU的模型與在整車的實際安裝位置關(guān)聯(lián)起來，整車總線束長度可以在拓?fù)鋵拥贸觥?/p>

信號路由是根據(jù)映射關(guān)系按照某些規(guī)則自動建立軟件層的數(shù)據(jù)元素（Data Element）與通信層的信號（Signal）之間的映射關(guān)系。軟件層路由的目的是將軟件層的信號流映射到硬件層中的連接線上。硬件層線束路由的目的是將硬件層中的連接線映射到拓?fù)鋵又械木€槽中。

圖6 模型元素的關(guān)聯(lián)關(guān)系

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

通過這種模型層與層之間的關(guān)聯(lián)從而實現(xiàn)模型元素所有層級之間的關(guān)聯(lián)關(guān)系，形成一個完整的電控模型，而工程師只需要勾選對應(yīng)的功能特征就可以在一定的規(guī)則下抽取出該功能特征對應(yīng)的所有模型元素，實現(xiàn)了電子電氣架構(gòu)的分層式及統(tǒng)一化開發(fā)。

3 硬件資源管理開發(fā)方法

根據(jù)上述軟硬件模型的創(chuàng)建方法，軟件組件已經(jīng)與硬件層的ECU建立了映射關(guān)系。因此，基于整車電控系統(tǒng)的變體管理實現(xiàn)基于系統(tǒng)方案的硬件資源管理方案。

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

圖7 硬件資源管理方案

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

表1 ECU 資源表

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

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

4 總結(jié)

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