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

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

引言

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

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

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

1 PREEvision層級(jí)介紹

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

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

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

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

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

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

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

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

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

“功能網(wǎng)絡(luò)”遵從AUTOSAR標(biāo)準(zhǔn)的定義，包括邏輯傳感器、功能塊和邏輯執(zhí)行器。這些元素（也被稱為功能模塊）以層次結(jié)構(gòu)的方式組織并存儲(chǔ)在組合模塊中。功能模塊之間通過信息交互接口進(jìn)行連接。當(dāng)兩個(gè)功能模塊的端口通過信息交互接口連接后，相應(yīng)模塊就能進(jìn)行數(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ā)過程的各個(gè)階段都會(huì)被用到。在早期的設(shè)計(jì)階段，它被用于確定所有電子電器部件內(nèi)部連接的最優(yōu)架構(gòu)方式；在設(shè)計(jì)階段，網(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)連接、地線和供電連接等。部件之間的所有連接通過不同的接口來實(shí)現(xiàn)?？蓪⒚總€(gè)具體接口配置為定義了通用屬性的特定接口類型。通過網(wǎng)絡(luò)層的描述，可以構(gòu)建部件設(shè)備內(nèi)部對(duì)外連接的總體關(guān)系，如圖4所示。

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

圖5 接口類型選擇

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

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

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

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

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

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

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

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

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

圖7 硬件資源管理方案

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

表1 ECU 資源表

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

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

4 總結(jié)

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