許茜,王蘭
(華晨汽車工程研究院電器工程室,遼寧 沈陽 110141)
當前車載電氣電子系統(E/E)系統按功能典型分為動力總成域、底盤域、車身與多媒體域。在車身域又典型地分為舒適性系統與被動安全系統。為使用戶得到更好的駕駛體驗,高級輔助駕駛(ADAS)功能與車載網絡互連功能,進而衍生出兩個新的系統,高級駕駛輔助系統與集成T-box的中央網關,又被稱為”Car2X”,如圖1所示。車載E/E系統提供的眾多功能中可以分為開環、閉環、監控與診斷功能,這些功能與使用傳感器與執行器的車輛機械零部件進行信息交互。有些功能只在一個域的內部進行信息互連互通,但是也有些功能需要跨域并與其他域的系統進行信息交互,特別的,ADAS高級輔助駕駛系統與發動機管理系統(EMS)、變速器控制系統(TCU)、轉向及制動系統緊密地集成。因此,幾乎所有的E/E架構開發的準則都直接或間接地受到ECU網絡設計以及功能集成開發的影響。線束與車載通信的需求是重要的評價準則,應該在E/E架構設計與優化的前期受到重視。

圖1 集成中央網關和ADAS系統的E/E網絡拓撲
在E/E架構設計中,一方面需要考慮基于與車外網絡通信的功能需求,另一方面集成雷達與攝像頭的ADAS為駕駛者提供整個車輛的環境模型并對于車外的網絡通信提出更高性能的需求。
以太網技術在整車E/E系統架構中的運用對于車內網與車外網來說都是一個重要的變革,越來越多國外的整車廠將其應用到了量產車中,并有望成為能夠廣泛應用的下一代技術標準。但是這并不意味著以太網會是唯一使用的車載通信技術。
對于功能的需求從而不再像過去一樣僅僅局限于車內網絡平臺,也能夠擴展到車外構架在云端或智能手機等無線設備等更多樣的網絡上。
與車外網絡互連對于車輛安全的方面提出了更為嚴苛的考驗,E/E架構設計必須滿足安全的需求。在過去幾年當中,ISO 26262成為在汽車行業廣泛接受的功能安全標準[1]。
總結以上內容,以下的幾方面將會影響甚至改變當前E/E架構的開發趨勢。
● 純電動及混和動力驅動方式;
● 高級駕駛輔助系統;
● 云集成;
● 手勢控制等新HMI。
在功能集成方面,多核ECU能夠提供所需的處理性能,以太網能夠提供所需的通信性能。
車輛的功能配置多樣性將會進一步增加,這意味著產品線管理、變型管理以及基于標準的平臺化設計方法更為重要。
對于典型域控制來說,基于AUTOSAR平臺的標準已經被廣泛接納[2]。但是基于Linux以及Android操作系統的平臺同樣也被納入在考慮范圍之內。
如何將所有的方面歸納整合并且設計最優化的 E/E架構,首先需要從整個系統的角度考慮,僅僅優化系統中的一部分只能導致局部的優化。其次,新概念的可行性需要在項目開發的早期階段進行分析研究以避免并減少開發過程中出現的風險。最后需要定義一個最優的目標架構。優化一個E/E架構有許多目標。當然,最困難的一些目標依然針對于整車。這組目標集合叫做全局車輛目標。以全局車輛為導向的 E/E架構設計目標有(圖2)。
● 成本限制
● 重量限制
● 封裝與幾何限制(例如線徑、絞距、主線束走向)
● 耗電量限制

圖2 E/E系統架構全局車輛目標
實際上,這些目標是作為整車目標而設定,E/E架構根據此目標數據得到相應的預期。這些目標主要從硬件和線束的方面影響E/E的零部件。
然而,系統架構的優化不僅僅局限于以上幾個目標,同樣存在另外的以功能實施為導向的目標集合。
以整車功能為導向的目標如圖3所示:
● 實時性需求(例如最大的通信延遲和電控單元(ECU)執行時間)
● 診斷服務請求(通過服務接口與空中下載(OTA))
● 總線負載限制(例如車載和車外通信的最大總線負載率)
● 安全與加密需求

圖3 E/E系統架構整車功能目標
基于PREEVISION的E/E架構設計并不是為了支持單獨的某個汽車,而是支持包括變型管理在內的完整的汽車產品線。
以產品線為導向的設計目標包括一下幾方面,如圖4所示:
● 考慮到變型、選配和產品線;
● 考慮到預期產量;
● 功能分解與零部件重用;
● 零部件與子系統重用策略。

圖4 E/E系統架構產品線目標
針對此目標的解決方式通常都是折中的結果,個別專用電氣電子零部件支持專用的變型(少量產品數量),相對的,通用類型電氣電子零部件支持所有的變型(大量產品數量)。
因此,評估并找出最佳的E/E架構是一個非常重要的設計優化問題,并且是包含多方面,多種類的問題。
PREEvision包含一套E/E架構設計相關中涵蓋的所有方面,可為架構的設計與優化提供一個基于方法的模型。所有在一個E/E架構設計中的需要各方面內容、概念均可以通過集成的方式建立模型。包括:
● 網絡與調度方面
● 硬件與結構方面
● 通信與軟件方面
● 功能、特性與需求
PREEvision通過多種模塊化分層結構支持產品線與產品變型模型來處理復雜的系統,以下為三個經論證的系統工程準則:
● 抽象化
● 分解
● 重用
圖5描述了PREEvision設計從線束細節到原理/電路圖再到ECU網絡層的縱向的抽象設計模型,軟件與通信細節的建模可并行設計。
PREEvision設計模型垂直方向從下至上依次為細化的線束層、系統原理圖以及ECU網絡層,細化的軟件及通信層與之并行建模。更為抽象化的是在其上層的邏輯架構層和需求、用戶特性層。

圖5 PREEvision 設計模型

圖6 PREEvision 數據建模系統工程準則
與垂直方向的分層化設計相對應,水平方向進行模塊化的分解設計。
與垂直、水平方向均相交的斜線方向為重用與變型,這說明了重用與變型在每一層級中均有體現。
PREEvision的產品線工程數據模型主要受到以下汽車行業相關標準的啟發:
● 用于需求及用戶特性的RIF[3]與ReqIF[4]特性與測試用例
● 用于系統軟件的AUTOSAR[2]通信設計
● 用于線束的KBL[5]與VEC[6]幾何規范
在PREEvision中,在硬件層與軟件層之上由其抽象化的邏輯設計叫做邏輯架構層[7]。考慮到車輛多樣性的功能,這一層在很多年一直保持穩定不變,然而軟硬件及通信技術卻在迅速的發展與變革。
總體上,PREEvision模型可分為以下幾個層級:
● 用戶特性層
● 需求層
● 邏輯架構層
● 軟件架構層(基于AUTOSAR)
● ECU網絡拓撲層(基于AUTOSAR)
● 通信層(基于AUTOSAR)
● 電氣原理圖層
● 線束層
● 幾何結構層
所有層之間通過映射的關系鏈接在一起。
用戶特性層用于為駕駛員與乘客提供便捷、舒適及安全等的用戶特性建立系統模型。由于用戶特性層作為整車產品線架構設計的起始點,在設計中應考慮到市場上所有的用戶特性而不能僅僅考慮某一單一車型的用戶特性。PREEvision的用戶特性通過樹狀結構來表示。不同用戶特性間的約束與聯系可以建模為FODA[8]樹狀驅動變型管理。PREEvision軟件集成的解析程序可確保在模型中篩選出需要的用戶特性。有效地特性選擇在特性模型框圖中被高亮,如圖7所示:

圖7 PREEvision中用戶特性模型
需求層支持任何種類的需求管理與工程設計,例如功能或非功能相關的法律法規。需求可以通過系統化的樹狀結構表示,使用戶能夠通過特定的使用用例定義和擴展需求屬性。Libre Office軟件功能完全支持需求的編輯。支持圖形,表格等豐富的功能格式。需求可以通過表格編輯器和 Libre Office編輯器編輯需求。每個需求都是一個帶有其各自歷史信息的樹狀結構可裂變對象。需求也可以是層級式的對象,使用RIF或Excel格式文件可以方便地導入需求。需求可以互相鏈接并且與其他層級的任意人工模型映射。需求的狀態可以通過所使用的產品生命周期定義。
邏輯架構提供圖像化的模塊視圖來構建整車的控制功能。傳感器功能、控制器功能、執行器功能以及環境功能等均可由不同類型的原子功能塊表示。同樣支持層級式構建模塊和邏輯域。此外,需要實現一個特定用戶特性的功能模塊可以分配一個活動鏈,映射到該用戶特性上面。邏輯功能可以映射到ECU層,基于上述的框架模型,相關總線上的需求信號的產生及觸發可以通過PREEvision來表示。
軟件架構層支持完整的AUTOSAR軟件架構框架。軟件部件可通過可視化的圖形模塊化,如圖8所示。

圖8 PREEvision中軟件架構框圖
ECU網絡拓撲層將產品線電控單元,網絡通信,供電,接地以及集成的傳感器與執行器建模。這樣也可以將許多AUTOSAR ECU網絡考慮在其中。圖9表示一個帶有4個電控單元交互的總線系統。

圖9 PREEvision中軟件架構框圖
PREEvision支持基于AUTOSAR的通信設計流程,首先,軟件架構與ECU網絡平行設計,其次將軟件組件映射到ECU當中。下一步PREEvision工具能夠檢測出這些AUTOSAR數據元素中哪些需要發送到總線上,創造出需求的系統信號并將每個系統元素映射到一個系統信號上,這一設計步驟在AUOSAR中叫做數據映射, 一種集成式信號路由程序使用Dijkstrás算法[9]為每一個信號找出最優化的路徑并創造出包括網關ECU通信在內的所有相關信號的觸發。基于這一步驟,所有總線片段通過通信技術中的PDU設計,幀與調度方法來完成。到目前為止,PREEvision支持CAN,CAN FD,LIN與 FlexRay,即將釋放的版本可支持以太網。最后,可計算出每個總線片段的總線負載率。

圖10 PREEvision 中通信設計方法
PREEvision通過4個層級的模塊化設計方法為整車線束的設計提供便利。它們分別是:ECU網絡拓撲,架構原理圖,線束與幾何結構。
ECU網絡層的目標是對于各個ECU在不同項目中的重用來最大化產品的生產效率。模塊化地設計包括供電,保險以及接地概念的電氣網絡架構。
在原理圖層,相同的原理圖設計典型地用于一個家族式的使用完全不同的幾何結構的各種衍生車型。
線束層將目標聚焦于所有線束相關的細節,設計的主要驅動力將作為一個特定的衍生車型的幾何結構的基礎。例如轎車,SUV,Coupe或箱貨車。
典型地,幾何拓撲層通過 CAD軟件獲取并導入到 PREE-vision中。
這幾層均用圖解形式的框圖表示,從線束原理層到幾何結構的路徑可以由線束路由器工具實現-再一次支持 Dijks-tra′s算法。線束的設計提供所有E/E架構需要的幾何結構相關的答案:線長,線徑,線重及由此帶來的成本,如圖11所示:

圖11 PREEvision中幾何結構圖
網絡安全及防護方面可以通過危險與風險分析方法(HARA) 考慮和分析,失效模式與效果分析(FMEA)與故障樹分析方案可提供使用。
先進駕駛員輔助(ADAS)與云集成這兩個新領域(圖1)需要得到以太網技術與網絡安全技術的充分支持。在新的版本中(V8.0),這兩方面將作為PREEvision的模塊化解決方案的補充。
基于方法的集成模型提供了信息的單一來源。模型可用于檢測設計的一致性與完備性。一組滿足用戶特性模型的特性篩選定義并且映射到其他層中。這一方法可以允許E/E架構通過給定義的特性篩選而完成。
PREEvision模型可以通過單獨定義的最優化目標和權值來評估。
此外,模型支持團隊協作,也就是說PREEvision可作為一個團隊協作的平臺。不同的E/E架構設計能夠在同一產品線上并行工作,所有的架構工件在版本控制下映射到權證以實現整個E/E架構的協同更改與釋放管理。
典型地基于模型架構設計并不是從零開始。普遍的,當前的 E/E架構將作為下一代架構優化創新設計的基礎。(圖12)。

圖12 典型的架構設計步驟
典型的架構設計步驟為:
(1)通過 Excel, EIF, AUTOSAR,DBC[10],LDF[11], FIBEX[12],KBL或特定的格式的文件導入數據到E/E架構中;
(2)歸并,整合并驗證所導入的數據;
(3)考慮各種可選方案設計下一代E/E架構的創新點;
(4)沿用用戶定義的優化目標和權值在一個質量指標下評估并分析設計可選方案和整個E/E架構;
(5)總結E/E架構設計報告并輸出設計方案,并將此作為一系列研發中項目的設計起始點。
此外還包括:
圖形化示意圖
基于編輯與瀏覽的圖表
多樣化的工程與代碼重構工具(例如上文中提到的信號與線束路由器)。
這一方法有益于E/E架構設計新人在一系列研發項目和產品批產前高質量目標下的快速的入門與實施。
架構設計并不僅僅作用于產品開關的開始,而且與產品的開發的并行設計。
架構的決策和重設計將在系列產品開發及下一代架構定義中連續不斷的進行著。架構設計與系列產品的開發的互動與交流在任何時間都是絕對強制的。
通常意義來講,E/E架構為特定的車型配置進行定量的指標評估(圖13)。
基本款車型:
標準的E/E功能應在合理的成本內交付,成本/性能比為主導的設計準則。
暢銷款車型:
典型的E/E功能應考慮的最高的期望產量來交付;
最高配置車型。
所有的E/E設計與設置需要從設計期望及約束條件方面考慮以協同工作,例如重量,封裝,總線負載,能量功耗等等。預期的產量是低的,但是價錢是卻最高的。成本指標在E/E架構中并非占支配地位的。

圖13 設計案例
這意味著優化目標不僅僅是多維的,也因車型配置和用戶特性選擇不同而不同,并且優化的目標會改變,如果隨著時間變化,可選的功能配置被用戶廣泛地接受,甚至可能成為了標準配置車型的一部分。
基于所有因素,汽車工業中廣泛可接受的優化目標是不存在的。針對于E/E架構方面來看,每個整車廠的優化目標及優化程序或多或少都是特定的。優化策略甚至當作為知識產權,這意味著PREEvision作為工具需要靈活的可定制的優化策略。因此完整的數據模型可被腳本語言支持并且通過JAVA代碼可以支持開發用戶特定的最優化腳本。數據模型可以通過權值來評估而被腳本所更改。使得用戶可以利用工具自動地執行以及運行模型和最優化策略,或者建模特定的場景和替代方案,通過個例分析做出均衡決策。
基于E/E架構設計與優化方法的模型需要考慮并且支持新一輪的交通車輛的變革。科技革命所帶來的汽車新功能增加了對于安全方面的需求,使得以太網通信技術的引入。很多優化目標需要被考慮,優化目標可以分為不同的種類。僅考慮一種類而忽略其他種類的方法是不充分的(例如 僅僅硬線相關的模型及權值)。PREEvision產品線模型支持所有汽車標準相關方面。定量的優化目標試用于專用的車輛配置。優化目標與權值是可以靈活配置的。
未來汽車的E/E系統方面功能的增加提升了架構設計與決策在項目初期的重要性,但是架構設計同樣可在項目開發過程中并行進行,架構設計,作為一系列開發的出發點,需要無縫地移交到產品設計工具上,反之亦然。
參考文獻
[1] ISO International Organization for Standardization: ISO 26262:Road Vehicles - Functional Safety.
[2] AUTOSAR:Automotive Open System Architecture: www.autosar. org.
[3] RIF: Requirements Interchange Format: www.automotive-his.de/rif.
[4] ReqIF: Requirements Interchange Format: www.omg.org/spec/ReqIF.
[5] KBL: Kabelbaumliste: www.vda.de.
[6] VEC: Vehicle Electric Container: www.vda.de.
[7] SPES 2020: Software Plattform Embedded Systems: spes2020. infor-matik.tu-muenchen.de.
[8] Kang Kyo C., Cohen Shologm G., Hess James A., Novak William E.,Spencer Peterson A.: Feature-Oriented Domain Analysis (FODA)Feasibility Study, Technical Repurt CMU/SEI-90-TR-21 ESD-90-TR-222, November 1990: http://www.sei.cmu.edu/reports/ 90tr021.pdf.
[9] Dijkstra′s algorithm:https://en.wikipedia.org/wiki/Dijkstra%27s _algorithm.
[10] DBC: www.vector.com/vi_candb_en.html.
[11] LDF: LIN Description File: www.vector.com/vi_local_interconnect_network_en.html.
[12] FIBEX: Fieldbus Exchange Format: www.vector.com /vi_fibex_ en.html.
[13] PREEvision: www.vector.com/vi_preevision_en.html.