商用車電子電氣架構開發

周文生

（集瑞聯合重工有限公司， 安徽 蕪湖 241000）

汽車發展至今， 已不僅僅是代步工具， 正在從傳統的機械裝置逐步電氣化， 汽車電子電氣功能不斷的豐富， 越來越多的電氣系統和功能被集成到汽車上， 是集動力、 安全、 舒適、 娛樂等性能的綜合體， 同時對整車電子電氣系統的性能、 功能、 成本、 可靠性及開發周期等各方面的要求也日益提高。 鑒于以上原因， 傳統的單元原理搜集到線束原理制作的開發模式已經不能滿足開發需求， 而整車電子電氣架構的概念就應運而生。

1 電子電氣架構概念

整車電子電器架構定義了電子電器系統、 子系統、 模塊和功能之間的關系和邏輯。 架構的基本構成元素是功能，是一個以需求為導向， 以功能實現方式為主導的平臺化系統性技術方案。 電子架構開發是電氣系統的頂層設計， 其必然打破沿襲的系統設計及零部件設計， 需要各個電氣系統統籌合力才可以取得收益。 為此電子架構開發是根據用戶需求自上而下的正向開發理念， 與系統平臺化、 系列化、模塊化等互相支撐， 以車型平臺的需求為基礎， 兼顧成本、性能、 品質、 可靠性、 駕駛環境、 環保等因素， 綜合評估優化而得出的最優的整車電子電氣系統模型。

2 電子電氣架構開發的意義

傳統的系統迭代開發方式， 具有效率低、 維護困難、低復用性等特點。 整車電子電氣架構承接整車架構開發的需求， 是通過多維度技術方案評估， 制定高性價比的電氣系統解決方案。 實施跨系統、 多維度技術方案綜合評估，構建完善的正向開發流程體系， 合理提升電氣平臺功能可擴展性， 打造自己的電子電氣系統 “基因” 特征， 同時可以強有力地打造公司的零部件通用化戰略， 貫徹公司提倡的產品 “正向開發” 思想， 提升開發能力。

3 開發需求及思路

針對某重型卡車的需求， 研究開發新一代重卡總線網絡平臺。 網絡平臺開發包括整車各節點功能分配設計、 確定總線網絡拓撲結構、 開發及評估整車電子電氣架構模型；開發整車網絡通信規范 （物理鏈路層規范、 網絡層規范、應用層規范、 網絡管理規范）、 網關規范、 網絡診斷規范、各控制器網絡需求規范、 整車網絡仿真模型、 網絡測試評價規范、 網絡分布式功能測試規范、 BCU全功能測試規范、測試臺架方案制定、 搭建測試環境、 開發測試程序及基于dSPACE系統的硬件在環測試。

在項目開發的不同階段， 在臺架及樣車上進行部件及系統測試驗證， 達到批量量產的目的， 最終形成可滿足今后不同配置車型的網絡需求， 可復用的總線網絡平臺。 同時該平臺支持生產管理 （EOL、 調試診斷等） 和服務管理（遠程管理和遠程診斷）。 為了使新開發的電子電氣架構具備更好的拓展性及適用性， 在產品開發時要滿足以下三要素： 方案的平臺化， 產品的系列化、 模塊化。

3.1 平臺化開發思路

整車電子電氣架構設計的主要任務是建立一個統一平臺， 來滿足不同的整車車型和定位。

電子電氣架構產品覆蓋某一款商用車U系平臺所有車型， 包括牽引車、 載貨車、 工程車及系列衍生車型， 在開發的過程中充分考慮電子電器架構的兼容性和可擴展性，即通過設計架構的魯棒性可以實現不同種類車型在同一電器架構下， 通過增刪節點來實現不同配置的功能要求。

3.2 系列化思路

整車電子電氣架構系列化包括功能系列化和控制器系列化。 在電子電氣架構的系列化過程中， 離不開各個子系統的模塊化和對功能模塊化分析， 這是實現系列化的重要保證。

控制器的系列化， 主要是指同一控制系統在滿足不同等級的功能需求時所劃分的系列， 系列化的主要依據是該控制系統在功能需求方面的系列化。

3.3 系統模塊化

模塊化主要體現在控制器產品的模塊化、 功能模塊化以及接口定義的模塊化， 其中接口定義的模塊化包含了軟件接口定義模塊化和硬件接口定義模塊化。

功能模塊化是指在設計整車功能時， 功能相關或相近的， 集成到一個控制器中。 基礎功能和對基礎功能進行拓展的高級功能， 可以集成到一個控制器中。

接口定義的模塊化是針對某一款商用車U系平臺系列車型， 根據功能需求適當調整控制器的硬件接口和軟件接口， 但是接口定義基本保持一致。

控制器的模塊化則依據功能模塊最終確定， 在控制器模塊化后， 其軟件接口和硬件接口的模塊化即相應完成。

4 電子電氣架構開發

電子電氣架構的開發分為3個階段： EE架構設計開發階段、 網絡設計開發階段、 測試驗證階段。 第一階段EE架構設計時， 功能定義為電氣系統的基礎， 這是整個EE架構設計的需求； 一個不完整的功能定義， 會對EE架構的開發產生巨大影響， 因此功能定義一般會隨著整個項目的進展和時間的推移會進行補充， 但不會增加。 因此在后期的架構設計階段， 必須考慮功能的可擴展性。

4.1 第1階段：整車電子電氣架構設計開發

4.1.1 分析對標階段

通過建立項目組， 確定項目開發計劃、 項目開發流程及項目管理方式， 明確各個階段的輸出物及模板， 確定各交付物的品質要求。

通過對競標車的分析對其電子電氣架構和網絡系統進行解析， 通過測試得到競標車的功能分配方案、 電源分配及保護方式、 網絡拓撲、 整個線束的實際布線方式、 各網絡節點的電氣參數、 各節點喚醒休眠機制、 電平衡測試分析、 通信矩陣、 通信的機制、 網絡管理機制、 診斷機制等信息。 明確競品狀態， 并圍繞競標車的狀態進行技術對標，以便指導后續的電子電氣架構和網絡系統設計。

同時對供應商的開發能力、 品質保障能力和生產能力進行全面評估， 以保證供應商能夠順利按照產品要求完成工作。 向供應商釋放項目開發調查表， 應包含如下詳細信息： 產品功能、 技術指標、 接口定義、 硬件型號、 軟件架構、 總線系統一致性開發策略、 軟件開發環境、 信號需求、診斷機制、 用戶開發環境的開放性、 開發能力、 配套經驗、開發周期等。

整車電子電氣架構設計必須對客戶的開發需求進行精準分析。 開發需求分析包括： 功能需求分析、 沿用件分析、成本分析、 競標車電子電氣系統分析、 法規及其他特殊要求分析、 ECU/傳感器/執行器布置需求分析等。

根據整車配置表整理出整車電器功能列表， 對功能進行危害、 風險、 安全等級、 重要程度分級， 確定控制管理類型， 結合競標車解析報告及開發需求得出整車功能矩陣，再結合以往經驗對整車功能矩陣進行細化， 并按照整車子系統對功能進行分類管理。

收集沿用件清單和以往項目收集的資源， 綜合所收集部件的狀態和電氣特性， 了解車型銷售的目標市場及特殊的要求， 在此基礎上進行整車架構的分析并制定開發需求分析報告， 根據分析報告對需求進行開發， 需求包括： 功能需求、 配置需求、 市場需求等。

4.1.2 設計開發階段

4.1.2.1 概念設計

根據開發需求， 參考競爭車型和以往車型的電子電氣系統， 結合競爭對手狀態、 未來電子電氣架構的發展方向以及項目工程人員的經驗， 進行危害及風險分析、 功能安全需求分析， 按照開發需求分析結果制定2～3種可行的概念方案， 其中需包含： 功能設計、 網絡管理、 診斷方法策略。同時， 根據概念方案結合其經驗提出至少3種不同的架構方案。 架構方案需反映網段劃分、 網絡協議類型、 網絡拓撲類型等內容。 概念設計主要包括： 需求層的定義、 功能清單及特性庫開發、 功能網絡開發、 硬件系統的架構和網絡層設計等， 確定初步架構評估算法。

4.1.2.2 ECU功能分配

該階段應該明確地將各種功能分配到不同的ECU中，并確定各控制器， 根據概念設計階段設計的架構方案， 細化各ECU的功能， 整理出各功能需求在各ECU間傳遞的信號。 同時結合概念設計中子系統的方案來定義各類信號在不同ECU間傳遞的邊界條件， 信號傳遞的硬線連接方式和報文形式， 然后對關鍵的信號提出實時性、 安全性及抗干擾性的要求。

根據架構概念方案， 功能分配方案以及整車信號列表完成以下工作： ECU功能列表 （文檔）、 整車信號列表、 信號傳遞關系表文件。 根據以下要求制定3種整車網絡拓撲結構： 網絡平臺的可擴展性、 傳輸實時性要求、 網絡容錯機制、 總線仲裁外的安全優先機制、 相關法規要求、 網絡負載率、 成本要求、 網絡開發中的其他需求。

4.1.2.3 電源及線束方案

確定整車電源方案和線束布置方案， 電源方案包括：電源分配、 電源管理、 搭鐵點、 保護選擇以及電平衡設計等。 電源分配主要基于以下幾點考慮： 電源模式負載失效情況下的隔離、 負載曲線、 考慮不干凈的負載、 休眠狀態下功能最低、 線徑優化以及線束布置EMC相關對線束布置的要求。

4.1.2.4 子系統功能規范設計

根據最終確定的整車電子電氣架構方案和各節點功能，設計各子系統功能規范。 子系統功能規范主要包括各子系統邏輯框圖、 功能控制條件、 控制邏輯、 信號傳遞接口定義、 診斷要求等。 子系統功能規范應該在系統層面對信號接口、 功能邏輯、 功能應用、 API接口形式和診斷方式進行規定， 確保各子系統對于BCM、 BBM、 VCU、 GW等柔性節點具有應用層面可編輯修改的功能， 對其他節點具有標定的能力， 同時可以指導各ECU的開發以及后期的系統測試， 以保證電子電氣架構開發成果可以順利過渡到各零部件開發。

4.1.2.5 整車電子電氣架構評估

整車電子電氣架構評估通過確定的評估算法， 對各種不同的電子電氣架構模型進行評估。 評估項目包括： 成本、品質、 可靠性、 安全性、 擴展性、 訪問性、 開發工作量等。通過計算得出不同架構量化的對比指標， 并根據對比指標確定最終的電子電氣架構。

4.2 第2階段：網絡平臺設計開發

網絡平臺設計開發包括： 整車網絡規范開發、 系統仿真設計、 網絡測試規范的開發。 這一階段制定的規范能夠指導產品開發和后期測試， 是整個網絡開發過程中的重要環節。

4.2.1 網絡規范開發

4.2.1.1 網絡通信規范開發

整車網絡通信規范包括： 各網段網絡物理層/數據鏈路層規范、 網絡應用層規范、 網絡管理規范、 網關規范。 在網絡通信規范開發過程中， 應建立早期失效模式控制方案，降低系統開發風險。

1） 網絡物理層/數據鏈路層規范設計。 需參考相關國際標準和開發需求， 并結合以往經驗， 制定物理層數據鏈路規范。 主要內容包括： 物理層和數據鏈路層特征、 要求及檢測方法、 總線運行要求、 喚醒技術、 總線電氣參數、總線的位定義、 總線終端、 總線接線要求、 總線管腳的ESD保護。

2） 網絡管理設計。 設計的網絡管理主要內容需包括：網絡監測和管理機制設計、 總線喚醒和睡眠的同步機制設計、 信息的優先級、 Start延遲機制、 離線節點的監控和網絡通信錯誤的檢測設計、 網絡節點控制器的狀態管理。

3） 總線應用層規范設計。 參考相關國際標準 （SAE J1939）， 并結合其經驗制定應用層規范。 主要內容包括：消息ID、 消息周期、 信號的更新率、 信號的精度、 消息延遲率、 信號初始值與失效默認值、 PGN、 SPN的自定義管理。

4.2.1.2 網絡診斷協議開發

網絡診斷規范的開發包括物理層、 數據鏈路層、 網絡傳輸層以及應用層規范的設計， 對診斷儀和各ECU節點之間的請求響應服務、 通信邏輯、 定時與錯誤處理機制進行規定。 針對ECU開發過程中的標定工作， 配合動力系統相關工程師完成標定協議內容和OBD故障檢測等內容的制定；針對生產線裝配過程中的整車電氣系統配置應用下載管理功能及檢測， 制定出可供參考的EOL配置、 標定及檢測等流程性規范。

4.2.2 系統仿真設計

1） 建立整車通信數據庫。 使用專業工具進行系統級的網絡設計， 通過報文發生方法的屬性來描述通信過程， 對仿真系統進行負載率分析、 延時分析、 時序分析、 一致性檢驗等， 最后應導出*.dbc文件， 實現和CANoe的無縫連接。

2） 建立整車診斷數據庫。 使用CANdelaStudio進行診斷數據庫設計， 輸出*.cdd文件。 利用DiVa軟件根據CANdela診斷數據庫 （cdd文件） 自動生成CANoe測試模塊。 當執行測試時， CANoe可以根據測試結果自動生成清晰簡明的報告。

3） 輸出各ECU通信數據庫。 在CANdb++環境下打開整車通信數據庫文件， 與節點供應商協商， 生成各ECU通信數據庫。 將各ECU數據庫文件轉換成相應的Excel格式的文件。

4） 整車網絡仿真。 使用CANoe建立整車網絡仿真。 根據網絡規范建立仿真模型、 設計人機交互界面、 開發仿真程序。

4.2.3 測試規范開發

在已經設計開發出的網絡通信規范和診斷規范的基礎上， 制定相應的網絡測試規范， 并根據零部件的功能規范開發相應的測試規范。 網絡測試規范主要是明確網絡測試的內容， 測試規范里包含所有的測試項內容以及對每一測試項測試所需要的測試環境需求、 測試步驟、 測試工具需求的描述。

網絡測試規范有兩類： 第1類是整車使用的網絡測試規范， 功能測試規范、 網絡管理測試規范。 第2類是釋放給各節點供應商的網絡測試規范， 分為網絡管理、 物理層和信號列表測試規范。

4.3 第3階段：測試驗證

測試驗證階段主要對供應商開發的產品進行單元和系統集成測試， 解決產品中存在的問題， 確保產品按照要求正確設計， 滿足可靠性要求， 具備量產條件。

4.3.1 搭建測試試驗平臺

測試平臺滿足單元測試和系統測試的要求。 根據相關測試規范及整車電子電氣功能需求， 編寫測試臺架需求與測試臺架方案。 方案應包括： 詳細的功能描述、 圖紙、 軟件硬件采購清單、 預算、 實驗室布置要求等。

試驗臺架需要滿足以下測試的需求： 物理鏈路層、 網絡管理、 應用層、 網關功能、 網絡分布式功能、 BCU全功能、 網絡系統功能以及診斷功能。

4.3.2 測試實施

整車網絡測試的目的是對供應商開發的產品進行系統集成和測試驗證， 確保產品的正確設計和開發試制。 主要包括以下幾個階段： 第1階段為網絡管理臺架測試及物理層測試階段 （第1輪測試）； 第2階段為網絡分布式功能臺架和樣車測試階段 （第2輪測試）； 第3階段為OTS臺架及樣車測試 （第3輪測試）。

4.3.2.1 網絡管理臺架測試及物理層測試階段（第1輪測試）

在開始全功能臺架測試前， 完成網絡管理臺架測試及物理層測試。 測試需結合產品的實際開發進度， 目的是確保整車網絡系統的正常運行。 因此， 網絡管理測試樣件可以不具有應用功能， 但必須集成網絡管理功能， 發送應用幀信息、 網絡的硬件應與最終產品相同。 對于診斷功能的測試， 主要是對各ECU節點的物理尋址請求響應服務、 應用層定時參數、 網絡層流控制幀傳送參數進行測試， 以及否定響應情況下， 返回不同否定碼的產生條件測試。

4.3.2.2 功能臺架和樣車測試階段 （第2輪測試）

1） 功能臺架： 在開始OTS臺架測試前所有測試問題必須整改完成。 測試目的是結合實際開發進度和項目裝車要求， 分步驟對網絡分布式功能及BCU全功能進行測試驗證，確保整車網絡分布式功能和BCU功能的正確實現。

2） 樣車功能測試： 根據前期對整車項目組提出的網絡測試樣車的要求， 在整車做各系統驗證時提供網絡測試用車， 在實車上對網絡功能、 網絡分布式功能、 BCU全功能進行動、 靜態驗證。

3） 樣車診斷測試及診斷儀測試： 該階段在之前診斷功能測試的基礎上， 采用CANoe對診斷請求響應過程進行監測， 通過對診斷儀的操作， 進一步測試應用層診斷服務、網絡層的數據傳輸規則以及應用層的響應時間參數。

4.3.2.3 OTS臺架及樣車測試 （第3輪測試）

這一階段的測試主要是在臺架和實車上對OTS樣件進行測試， 確認其網絡開發的正確性， 為產品的最終認可工作做準備。

5 結語

架構設計是一門分與合的藝術。 架構工程師需要從多個角度， 建立汽車電氣系統的全局性設計規則， 使復雜的汽車電氣系統便于理解。

未來汽車的競爭在很大程度上是汽車電子電氣功能上的競爭， 且模塊化、 系統平臺化已經成為汽車行業發展的必然趨勢， 而電子電氣架構的設計正是實現整車電子電氣系統平臺化、 模塊化的唯一途徑。 設計出一個最優化的電子電氣架構， 在某種意義上即實現了整車電子電氣系統的正向開發， 而這也為聯合卡車 “做高端產品” 的定位打下了堅實的基礎。