簡介

隨著 OEM 開發的高級平臺的自動化和連通性水平不斷提高，各領域的車輛復雜性都在增長。為了應對這種日益增長的復雜性，汽車、航空航天和商用車輛 OEM 必須發展架構設計流程，以利用 MBSE 和數字化流程。當今的 E/E 系統工程解決方案通過提供穩健的數據連續性、高級自動化能力、閉環驗證和設計優化來幫助公司實現MBSE。借助此類解決方案，工程師可以使用現有功能模型來生成車輛架構和更詳細的系統設計，并持續從上游流程擴充數據，以確保從功能到實現以及實際組件或系統的可追溯性。這種可追溯性對于證明高級車輛平臺的合規性和安全性至關重要。

隨著車輛技術朝著更高水平的自主性和連通性方向發展，汽車、航空航天和重型/非公路車輛行業的原始設備制造商 (OEM) 開始面臨共同的挑戰（圖 1）。人們希望這些先進技術能夠改善乘用車、飛機、農業和其他重型設備的安全性、生產率及能力。然而，支持這些技術需要復雜的電氣、電子和機電系統，這促使所有領域的車輛復雜性急劇提高。

到目前為止，車輛的架構演變是由對更好的車輛功能、新型且更高級的特性的需求驅動的。例如，考慮過去 20 年中汽車電氣電子 (E/E) 架構的演變。以前，車輛架構由幾十個通過低帶寬網絡和低保真度信號連接的 ECU 組成。這些架構支持車輛的基本特性和功能，例如立體聲音響、電動車窗、巡航控制和防抱死制動系統。相比之下，現代中檔汽車包含約 90 個 ECU，這些 ECU 通過各種高速和低速網絡連接到數十個傳感器和執行器。這種現代架構在規模和復雜性方面有很大的增長，目的是支持新特性，例如先進駕駛輔助系統 (ADAS)、高級信息娛樂系統、導航等。

現在，更高級的車輛自動化、電氣化和連接系統正在推動車輛 OEM 廠商將新技術整合到車輛中。其中特別值得注意的是，制造商正在嘗試整合新的通信技術，以便將車輛連接到 5G 網絡、WiFi 并實現 “車輛到一切” (V2X) 的通信。利用這些通信技術，OEM 將能對車輛軟件進行空中更新 (OTA)，這樣哪怕車輛已售出，也能解鎖更多功能。但是，車輛架構中也需要額外的基礎設施來保障安全，防范來自車輛外部及其所連接的網絡的安全威脅。隨著車輛自動化程度的提高，這一點尤其重要。

圖 1：汽車、航空航天、重型和非公路行業的車輛的連通性和自動化水平越來越高。

此類演變的結果是車輛跨多個領域的復雜性激增。2014 年，德意志銀行開展了一項研究，基于典型車輛在不同時間的軟件代碼行數 (SLOC) 和網絡信號數量來測量車輛復雜性的上升。該研究預測，到 2020 年，平均每輛車將包含 3000 萬 SLOC 和 10,000 個網絡信號，這兩個數據均為 2012 年所報告數據的至少兩倍。然而，這一預測已被證明不符合實際（圖 2）。

根據我們與客戶的交流，2020 年的典型車輛擁有 1.5 億SLOC 和 20,000 或更多的網絡信號。新車輛技術的快速發展和集成推動車輛復雜性的增長，其速度超過了僅僅幾年前的預測。除了更復雜的車輛外，OEM 還必須管理所有這些軟件、網絡、電氣組件以及所有其他車輛系統和零件的生命周期。這涉及協調開發周期以支持先導計劃的啟動，同時要確保已納入后期計劃的要求。這當然是非常復雜的。OEM 在管理軟件和組件的生產壽命周期時，必須確保組件在每種派生車輛的生產和服務中得到適當使用，并且配置與每種車輛規格相匹配。這涉及組織中不同部門的多個團隊。

在設計和開發過程中，車輛定義中功能劃分的細小錯誤便可能導致安全相關功能所依賴的系統的完整性不足。這又可能導致后期計劃需要付出高昂代價來進行更改，或者更糟的是，車輛在使用中發生故障，需要召回以更新多個 ECU。不正確的組件配置也可能導致車輛功能錯誤或丟失，引起客戶不滿，并需要額外的成本來確定生產中和使用中受影響的車輛。管理這種復雜性并確保貫穿開發過程的可追溯性，對于打造先進的自動化聯網車輛并按照緊迫的時間表——這在當今汽車、航空航天和商用車輛行業司空見慣——將這些車輛推向市場至關重要。

圖 2：德意志銀行 2014 年開展的一項研究的預測結果遠低于 SLOC 和網絡信號的實際增長。

針對 E/E 架構設計的基于模型的系統工程

現代車輛復雜性的爆炸性增長要求改變設計方法。傳統方法依賴手動操作，工程領域被劃分為多個孤島，而未來的工程策略必須采用自動化，并通過穩健的數據完整性和集成解決方案來支持協作。基于模型的系統工程(MBSE) 以及先進的工程軟件解決方案組合，可以為開發現代汽車、飛機和商用車輛日益復雜的 E/E 架構提供這些關鍵能力。

基于模型的系統工程流程從功能模型開始。這些模型描述各種車輛系統和子系統的功能。例如，功能模型可以描述特定軟件組件、電氣信號或電子元器件，例如模數轉換器。這些模型常常是采用不同供應商的多種工具構建的。因此，這些模型背后的源數據是分布式的，彼此脫節。這種脫節的數據可能成為下游流程的一大痛點，尤其是在設計變更時。

各種系統的源數據必須標準化為通用數據模型，并整合為網絡、軟件、電氣、硬件和其他功能類型。將這些多樣化輸入標準化為通用數據模型非常關鍵，因為它使得整個 E/E 架構和其他下游開發流程都可以訪問車輛系統的源數據。

系統架構師可以使用標準化數據來創建 E/E 架構并提供完整的邏輯、網絡、硬件和軟件信息。然后，每個領域的工程師可以查詢 E/E 架構以獲取特定領域的信息，從而用于創建詳細的系統設計。例如，電氣工程師可以從架構中提取邏輯原理圖，然后使用其他信息加以完善和增強，以創建車輛網絡和電氣分配系統 (EDS)。接下來，可以使用網絡和 EDS 設計來提取離散的線束設計，然后利用這些設計創建制造數據，最終創建服務數據和特定車輛的維修文檔。

圖 3：數據連續性使開發各階段的數據能夠饋入下一階段，從而確保可追溯性并加快開發周期。

穩健的數據模型對于實現基于模型的工程流程至關重要；從定義到制造和服務，數據始終保持連續。數據連續性使得 EDS、網絡和軟件開發各階段的工作成果可 以用作流程下一步的輸入（圖 4）。數據在開發流程中上下移動的這種連續數字化流程，也會增強工程師管理和實施變更的能力。在實施之前便可理解設計變更的全部影響，因為每個領域都是基于同一數字化流程來工作。變更一旦得到驗證，便可將其快速傳播到所有受影響的領域和設計。

此外，數據連續性還提供了從功能模型到這些功能在車輛軟件、網絡和 EDS 中實現并形成文檔的可追溯性。這種可追溯性確保工程師可以快速識別車輛架構中任何組件的功能來源，或者（反過來）找到實現一項功能所涉及的特定 ECU、網絡信號或引腳。

MBSE 使工程師能夠利用各種環境中的現有功能模型和工程數據來創建車輛架構及更詳細的系統設計。通過持續從上游流程擴充數據，MBSE 確保可追溯性并簡化變更管理和實施。但是，整合模型、創建架構和維護可追溯性所涉及的許多流程仍然是手動完成的。現代 E/E 系統工程解決方案可以讓手動任務自動化執行，從而改善這些流程，并提供統一數據庫來確保整個 E/E 架構和系統設計的數據連續性。

增強 E/E 架構設計 MBSE 的關鍵軟件功能

當前，將功能模型整合到單個車輛平臺中是一個手動過程，需要大量時間和精力。功能模型存在于各種不同的系統工程工具中，每種工具都有自己的車輛功能抽象方法。在傳統系統工程工具中，僅僅完善一個這樣的模型以足夠詳細地表示其在車輛平臺中的實現，便需要巨大的手動工作量。將這一工作量乘以定義車輛平臺通常所需的數以百計或數以千計的模型，不難得知任務的規模是何等之大。

如今，E/E 系統工程解決方案（例如 Siemens DigitalIndustries Software 的 Capital）可以使很多工作自動化進行。高級 E/E 系統工程軟件不是在系統工程環境中添加必要的領域詳細信息，而是可以導入功能設計抽象，這樣工程師便可在平臺級別用軟件、硬件、網絡和 EDS的領域詳細信息修飾該抽象（圖 4）。然后，軟件使用基于規則的綜合功能，以后續領域工程流程所需的粒度在車輛平臺中部署功能。

這些專業 E/E 工程解決方案還有針對邏輯和物理關鍵性能指標 (KPI) 的內置指標，包括成本、帶寬利用率等。這些指標可以推動早期優化，并與基于規則的綜合一起推動 E/E 架構快速迭代。然后，設計規則檢查可以識別物理設計抽象中的違規或問題，例如超額帶寬或 ECU 利用率。例如，考慮一個在 Excel 中構建的軟件組件的功能設計。

E/E 工程解決方案可以導入此設計以及車輛需要的成百上千的其他設計，并部署該功能以創建車輛平臺。部署功能后，內置指標可以顯示架構中每個 ECU 使用了多少 RAM，以便工程師進行權衡。此外，工程師可以快速查看當前功能分配將在架構周圍的每個 ECU 中產生多少CPU 負載，如有必要則調整分配。完成調整后，工程師可以綜合更新后的架構，并以這種方式繼續完善。

圖 4：高級 E/E 系統工程解決方案允許工程師修飾系統級別的功能抽象，從而加快架構和領域工程過程。

結果得到一個經過驗證的多領域車輛平臺，該平臺已經針對平臺 KPI 進行優化。生成平臺時，E/E 工程解決方案可確保從平臺到源功能設計的數據連續性和可追溯性。當不同團隊執行詳細設計工作以創建邏輯、網絡、軟件和硬件系統時，上述數據連續性還將支持團隊之間的協作和可追溯性。每個元件將自動關聯到其功能抽象和物理實現。線束中某個連接器上的單個管腳可以追溯到定義該管腳的接線圖、邏輯原理圖和功能設計。

Capital 之類的高級 E/E 工程解決方案則在此基礎上更進一步。與 Teamcenter 和 Polarion 等產品和應用生命周期管理解決方案 (PLM/ALM) 的集成，使數字化流程可以一直延伸回到產品配置、要求和約束（圖 5）。這種全面的可追溯性確保工程師可以了解架構中的每個組件或功能及其實現方式，還有它為什么要存在。其結果是，車輛 OEM 可以自動生成詳細而準確的合規文檔，而無需到處搜羅信息。

數據連續性和可追溯性還能簡化工程變更的管理、實施和傳播。有時候，即使出于合理原因進行的更改也可能導致使用中的車輛出現電氣問題。Capital 的數據模型使工程師可以查看和了解變更對車輛的影響。這種可見性可防止工程更改在其他相關系統中造成問題。自動化變更管理功能還可以將設計變更傳播到所有受影響的系統，確保其在全車得到正確實施。

圖 5：與 ALM 和 PLM 解決方案的集成使得數字化流程可以一直延伸回到產品要求和定義。

連接軟件開發與集成

現在，嵌入式軟件應用對于實現乘用車、飛機和商用車的車輛功能至關重要。軟件的重要性日益提高，這意味著工程師在架構設計和功能分配期間就要考慮這些應用。Capital Software Designer 是 Capital 套件的最新成員，支持軟件工程師直接與架構設計進行協作和同步，以在系統定義的背景下開發嵌入式軟件應用需求（圖 6）。根據這些需求，工程師可以協調軟件模型和控制算法，并在編寫代碼之前驗證功能。

Capital Software Designer 具有自動化和基于合同的軟件設計功能，支持軟件工程師將高層架構細化為要在軟件應用中實現的數字化組件。汽車、航空航天和重型設備領域的大型 OEM 廠商也擁有許多傳統軟件。工程師可以導入用 C、SysML、Matlab 和其他語言編寫的現有代碼，更新傳統軟件，使其能夠在新的車輛平臺中復用。無論哪種情況，必要的軟件組件都會連接到整體車輛架構，實現基于模型的軟件架構模型綜合。

集成的形式驗證技術可以在數學上證明軟件架構和軟件組件實現中沒有不一致的地方。Capital Software Designer 還能連接各種仿真環境，以對嵌入式應用進行模型在環、軟件在環、硬件在環和車輛在環 (MiL/SiL/HiL/ViL) 測試。它還支持對各種車輛抽象中的軟件架構和組件進行閉環驗證，從而確保軟件有效集成到架構中。同時，ECU 規范派生自 E/E 架構，允許在虛擬 ECU 模型的背景下開發應用代碼。這些 ECU 的基本軟件配置也可以根據提取的 ECU 規范進行開發和測試。

圖 6：Capital Software Designer 支持將軟件架構和組件設計集成到 E/E 系統工程流程中。

采用 Capital Networks，考慮完整網絡拓撲及其多種技術（例如 LIN、CAN、CAN-FD、FlexRay 和以太網），可以使用功能分配和信號定義來推導和設計車輛網絡。然后，可以使用全面的時序模型來驗證網絡設計的行為是否滿足功能要求，進而將“設計即正確”的輸出文件交付給內部團隊或一級合作伙伴。

接下來，可以使用 Capital VSTAR Integrator 配置AUTOSAR 基本軟件。該過程利用流程中早先的模型數據來構造和生成已配置的軟件模板，并根據內部規則和模型對其進行驗證，確保輸出準備就緒。然后，在目標硬件可用之前，可以使用 Capital VSTAR Virtualizer 虛擬運行軟件，使得行為驗證和調試可以在開發流程的早期進行，節省早期樣品硬件的寶貴時間。

基于 Polarion 的 ALM 框架將嵌入式軟件開發聯系在一起。ALM 跟蹤軟件開發，確保應用程序滿足平臺級要求，并提供全程可追溯性。ALM 還會協調軟件驗證和確認。工程師可以通過 ALM 解決方案觸發功能模型仿真，也就是將每個可用的車輛抽象結合起來，以了解完整車輛的虛擬模型在虛擬環境中會如何響應。這種方法不是創建物理原型，而是集成 MiL、SiL、HiL 和 ViL 仿真以反映車輛功能的多領域情況。與制作物理原型以進行早期驗證和確認相比，這可以節省相當可觀的成本和時間。最后，ALM 解決方案跟蹤每種派生車輛的應用配置和交付，確保交付的軟件支持每種車輛上的特定功能組合。

…………未完待續…………

更多詳細信息請點擊>>