分布式汽車電氣/電子系統設計和實現架構

在過去的十幾年里，汽車的電氣和電子系統已經變得非常的復雜。今天汽車電子/電氣系統開發工程師廣泛使用基于模型的功能設計與仿真來迎接這一復雜性挑戰。新興標準(如AUTOSAR)定義了與低層軟件的標準化接口，最重要的是，它還為功能實現工程師引入了一個全新的抽象級。

　　這提高了軟件組件的可重用性，但不幸的是，關于如何將基于模型的功能設計的結果轉換成高度分布式環境中的可靠和高效系統實現方面的指導卻幾乎沒有。

　　此外，論述設計流程物理端的文章也非常少。本文概述了一種推薦的系統級設計方法學，包括架構設計、分布在多個ECU中的網絡和任務調度、線束設計和規格生成。

為什么需要AUTOSAR?

　　即使在同一家公司，“架構設計”對不同的人也有不同的含義，這取決于他們站在哪個角度上。物理架構處理系統的有形一面，如布線和連接器，邏輯架構定義無形系統的結構和分配，如軟件和通信協議。目前設計物理架構和邏輯架構的語言是獨立的，這導致相同一個詞的意思可以完全不同，設計團隊和流程也是獨立的，這也導致了一個非常復雜的設計流程(如圖1所示)。

圖1：物理和邏輯設計流程。

　　這種復雜性導致了次優設計結果，整個系統的正確功能是如此的難于實現，以致于幾乎沒有時間去尋求一種替代方法，它可導致更堅固的、可擴展性更好的和更具成本效益的解決方案。為了實現這樣一種解決方案，設計師需要新的方法，它可以將物理和邏輯設計流程緊密相連，并仍然允許不同的設計團隊做他們的工作。

　　新興的AUTOSAR標準為系統級汽車電子/電氣設計方法學提供了一個技術上和經濟上都可行的選擇，盡管它主要針對軟件層面，即邏輯系統的設計。不過，大量廣泛的AUTOSAR元模型及其豐富的接口定義允許系統級電子/電氣架構師以標準的格式表達他的設計思想。從經濟上看，AUTOSAR標準打開了一個巨大的、統一的市場，它使得可以創建合適的設計工具。

　　本文描述了基于AUTOSAR的由點工具組成的系統級設計方法。這導致整個流程在所有有意義的地方使用標準，但又不局限于標準，或要求用戶采用這些標準。

AUTOSAR工作原理

　　AUTOSAR標準是汽車制造商、供應商和工具供應商一起發起的，旨在規范汽車電子控制單元(ECU)的開放式軟件架構。

　　AUTOSAR標準指定了一個分層軟件架構，它明確定義了應用軟件組件(SWC)之間的接口、用戶可見汽車功能和基礎設施組件的實現。它對基礎設施組件進行了嚴格的規定，以允許不同供應商開發的組件能一起工作。

　　用戶可見的汽車功能通過互連的應用軟件組件來實現。SWC是可以映射到ECU的最小單元。為了使SWC與特定的硬件無關，定義了虛擬功能總線(VFB)概念，此處SWC就使用VFB與它們的環境進行通信。

　　這一概念支持SWC重新定位到不同的ECU，從而增強了應用軟件的可重用性。

　　一個AUTOSAR系統基本上由以下三個XML文件定義：SWC描述、ECU資源描述和系統配置描述。這些文件描述了一個邏輯架構的所有方面：SWC、功能網絡、拓撲和功能到ECU的映射。雖然這些文件的語法和語義由AUTOSAR標準定義，但它們的創建方法學則留給了工具供應商。

用戶案例分析

　　下面兩個代表性用戶案例可以讓你更深入地了解到總體物理和邏輯設計任務的復雜性。

　　在圖2顯示的設計流程中，你可看到邏輯設計過程是如何驅動物理設計過程的。這一設計流程的第一步是汽車邏輯功能的定義和實現。大多數OEM將一部汽車的電氣系統分解成約100-200個功能。用戶創建能表達各種汽車功能的單元級SWC，或從像Matlab/Simulink這樣的模型設計工具中調用這類SWC。

　　由于SWC的規范和開發在時間和地點上都是高度分散的，以及許多SWC從許多不同的來源進入設計流程，因此應進行一致性檢查，以盡早發現錯誤。即便只有接口描述，也已經可以進行內部組件之間的接口一致性靜態檢查。在設計流程的這一點上，增加端到端的時序要求是重要的，以支持后面流程中要求時序信息的先進分析工具。

圖2：用戶案例1——邏輯設計驅動物理設計。

　　與此同時，可以創建一個有潛力的拓撲結構，它能勾畫出分布式汽車網絡的邏輯拓撲結構，以及描述傳感器、激勵器和ECU的連接。通常情況下，一個汽車項目開始于原有設計的重利用，然后對它進行修改。在重利用現有的ECU時，非常詳細的ECU信息可以來自企業數據庫，或需要定義新的ECU，其技術特性在開發過程中的特定期間是變化的。

　 在以上兩種情況下，功能信息和拓撲信息都可以提供給物理設計流程。物理設計過程的功能級也需要ECU上的數據(如總線系統使用的)。現在的物理設計需要一個子系統設計步驟，在該步驟上，在物理組件映射到汽車上的封裝空間(插槽)之前，如ECU和保險絲盒這樣的子系統需要做進一步的詳細設計。除此之外，在該步驟上，也可以開發出電源/接地概念。

　　邏輯架構設計的對應步驟是SWC映射到ECU。這也決定了SWC之間的通信方案，即多個SWC是通過總線系統還是內部ECU進行通信。

　　通信方法的選擇對物理設計有直接的影響，這也增加了整個設計過程的復雜性。例如，這取決于是否需要電線、常規電線、雙絞線或雙股雙絞線。

　　封裝步驟之后是物理系統集成，此處，CAD系統的信息用于添加額外的物理信息，如所需的在線連接器和布線通道。

　　這反過來對設計的邏輯層面有影響，并再次增加了整個設計過程的復雜性。太小的布線通道可能使得無法使用雙股雙絞線，或太長的電線長度可能使得將某個SWC重定位到另一個ECU上成為一個更具成本效益的替代選擇。

　　當物理和邏輯流程都可以提供結果以后，它們的各種數據就可用來評估和優化汽車架構。不過，由于流程的復雜性，很難找到一個以上行得通的架構。其結果是，邏輯和物理設計師只能嘗試優化其各自負責的設計部分。

圖3：用戶案例2——物理設計驅動邏輯設計

　　圖3顯示物理設計驅動邏輯設計的設計流程，邏輯拓撲是物理拓撲的衍生。與前面的增加信息不同，這里不必要的信息需要被過濾。例如，在需要一個雪茄打火機的物理設計時，這一功能并不需要一個SWC描述，因此這一信息在邏輯域中不需要。這兩個例子只是反映了今天現有的設計流程挑戰的一小部分，并說明了整個流程的復雜性。

物理和邏輯設計流程的集成

　　改善這個內在復雜設計流程(多個設計小組在同一整體設計上同時工作)的一個選擇是，兩個不同設計流程之間的緊密聯系。

　　在整個設計流程中，數據需要保持同步，但與此同時，工程師受到了這一同步的太多阻礙。在目前的工作流程中，所有的人都共享相同的數據對象，而且在使用它們之前必須對它們進行檢查，一種替代工作流程是，針對兩個不同的設計流程，使用兩個獨立的數據庫（見圖4），但找到一種辦法可以在不帶來大量人力工作量情況下保持數據同步。

　　這需要這樣的一個設計流程，大部分的設計實際上是自動生成，而不是手工生成。在同步過程中數據庫的變化將自動導致一次“綜合”操作，從而完全避免了重復以前努力的任務。

圖4：并行處理物理和邏輯設計

　　一個例子是網絡配置的生成。當需要通過網絡傳輸的信號發生變化時，設計師可以手動輸入這些變化，并手動運行所有必需的驗證測試，這可以導致設計過程的時間延長幾個月。與此形成鮮明對比的是，各種通信數據可以自動基于通信要求和數學算法生成，這可將完成設計流程所需的時間大幅減少到秒級。

　　一個類似的物理設計例子是系統集成。當系統出現變化時(如不同的路由通道)，人工過程需要太多的時間，而且容易出錯。通過使用一個自動生成的流程，系統的變化可以通過流程或多或少地馬上得到處理。例如，連接器的安裝位置改變和電線長度可以自動生成。在這里，工程師的know-how用于定義規則，而不是應用這些規則。