簡介

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

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

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

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

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

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

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

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

圖 2：德意志銀行 2014 年開展的一項(xiàng)研究的預(yù)測結(jié)果遠(yuǎn)低于 SLOC 和網(wǎng)絡(luò)信號的實(shí)際增長。

針對 E/E 架構(gòu)設(shè)計(jì)的基于模型的系統(tǒng)工程

現(xiàn)代車輛復(fù)雜性的爆炸性增長要求改變設(shè)計(jì)方法。傳統(tǒng)方法依賴手動操作，工程領(lǐng)域被劃分為多個孤島，而未來的工程策略必須采用自動化，并通過穩(wěn)健的數(shù)據(jù)完整性和集成解決方案來支持協(xié)作?；谀Ｐ偷南到y(tǒng)工程(MBSE) 以及先進(jìn)的工程軟件解決方案組合，可以為開發(fā)現(xiàn)代汽車、飛機(jī)和商用車輛日益復(fù)雜的 E/E 架構(gòu)提供這些關(guān)鍵能力。

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

各種系統(tǒng)的源數(shù)據(jù)必須標(biāo)準(zhǔn)化為通用數(shù)據(jù)模型，并整合為網(wǎng)絡(luò)、軟件、電氣、硬件和其他功能類型。將這些多樣化輸入標(biāo)準(zhǔn)化為通用數(shù)據(jù)模型非常關(guān)鍵，因?yàn)樗沟谜麄€ E/E 架構(gòu)和其他下游開發(fā)流程都可以訪問車輛系統(tǒng)的源數(shù)據(jù)。

系統(tǒng)架構(gòu)師可以使用標(biāo)準(zhǔn)化數(shù)據(jù)來創(chuàng)建 E/E 架構(gòu)并提供完整的邏輯、網(wǎng)絡(luò)、硬件和軟件信息。然后，每個領(lǐng)域的工程師可以查詢 E/E 架構(gòu)以獲取特定領(lǐng)域的信息，從而用于創(chuàng)建詳細(xì)的系統(tǒng)設(shè)計(jì)。例如，電氣工程師可以從架構(gòu)中提取邏輯原理圖，然后使用其他信息加以完善和增強(qiáng)，以創(chuàng)建車輛網(wǎng)絡(luò)和電氣分配系統(tǒng) (EDS)。接下來，可以使用網(wǎng)絡(luò)和 EDS 設(shè)計(jì)來提取離散的線束設(shè)計(jì)，然后利用這些設(shè)計(jì)創(chuàng)建制造數(shù)據(jù)，最終創(chuàng)建服務(wù)數(shù)據(jù)和特定車輛的維修文檔。

圖 3：數(shù)據(jù)連續(xù)性使開發(fā)各階段的數(shù)據(jù)能夠饋入下一階段，從而確?？勺匪菪圆⒓涌扉_發(fā)周期。

穩(wěn)健的數(shù)據(jù)模型對于實(shí)現(xiàn)基于模型的工程流程至關(guān)重要；從定義到制造和服務(wù)，數(shù)據(jù)始終保持連續(xù)。數(shù)據(jù)連續(xù)性使得 EDS、網(wǎng)絡(luò)和軟件開發(fā)各階段的工作成果可 以用作流程下一步的輸入（圖 4）。數(shù)據(jù)在開發(fā)流程中上下移動的這種連續(xù)數(shù)字化流程，也會增強(qiáng)工程師管理和實(shí)施變更的能力。在實(shí)施之前便可理解設(shè)計(jì)變更的全部影響，因?yàn)槊總€領(lǐng)域都是基于同一數(shù)字化流程來工作。變更一旦得到驗(yàn)證，便可將其快速傳播到所有受影響的領(lǐng)域和設(shè)計(jì)。

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

MBSE 使工程師能夠利用各種環(huán)境中的現(xiàn)有功能模型和工程數(shù)據(jù)來創(chuàng)建車輛架構(gòu)及更詳細(xì)的系統(tǒng)設(shè)計(jì)。通過持續(xù)從上游流程擴(kuò)充數(shù)據(jù)，MBSE 確保可追溯性并簡化變更管理和實(shí)施。但是，整合模型、創(chuàng)建架構(gòu)和維護(hù)可追溯性所涉及的許多流程仍然是手動完成的?，F(xiàn)代 E/E 系統(tǒng)工程解決方案可以讓手動任務(wù)自動化執(zhí)行，從而改善這些流程，并提供統(tǒng)一數(shù)據(jù)庫來確保整個 E/E 架構(gòu)和系統(tǒng)設(shè)計(jì)的數(shù)據(jù)連續(xù)性。

增強(qiáng) E/E 架構(gòu)設(shè)計(jì) MBSE 的關(guān)鍵軟件功能

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

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

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

E/E 工程解決方案可以導(dǎo)入此設(shè)計(jì)以及車輛需要的成百上千的其他設(shè)計(jì)，并部署該功能以創(chuàng)建車輛平臺。部署功能后，內(nèi)置指標(biāo)可以顯示架構(gòu)中每個 ECU 使用了多少 RAM，以便工程師進(jìn)行權(quán)衡。此外，工程師可以快速查看當(dāng)前功能分配將在架構(gòu)周圍的每個 ECU 中產(chǎn)生多少CPU 負(fù)載，如有必要則調(diào)整分配。完成調(diào)整后，工程師可以綜合更新后的架構(gòu)，并以這種方式繼續(xù)完善。

圖 4：高級 E/E 系統(tǒng)工程解決方案允許工程師修飾系統(tǒng)級別的功能抽象，從而加快架構(gòu)和領(lǐng)域工程過程。

結(jié)果得到一個經(jīng)過驗(yàn)證的多領(lǐng)域車輛平臺，該平臺已經(jīng)針對平臺 KPI 進(jìn)行優(yōu)化。生成平臺時，E/E 工程解決方案可確保從平臺到源功能設(shè)計(jì)的數(shù)據(jù)連續(xù)性和可追溯性。當(dāng)不同團(tuán)隊(duì)執(zhí)行詳細(xì)設(shè)計(jì)工作以創(chuàng)建邏輯、網(wǎng)絡(luò)、軟件和硬件系統(tǒng)時，上述數(shù)據(jù)連續(xù)性還將支持團(tuán)隊(duì)之間的協(xié)作和可追溯性。每個元件將自動關(guān)聯(lián)到其功能抽象和物理實(shí)現(xiàn)。線束中某個連接器上的單個管腳可以追溯到定義該管腳的接線圖、邏輯原理圖和功能設(shè)計(jì)。

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

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

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

連接軟件開發(fā)與集成

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

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

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

圖 6：Capital Software Designer 支持將軟件架構(gòu)和組件設(shè)計(jì)集成到 E/E 系統(tǒng)工程流程中。

采用 Capital Networks，考慮完整網(wǎng)絡(luò)拓?fù)浼捌涠喾N技術(shù)（例如 LIN、CAN、CAN-FD、FlexRay 和以太網(wǎng)），可以使用功能分配和信號定義來推導(dǎo)和設(shè)計(jì)車輛網(wǎng)絡(luò)。然后，可以使用全面的時序模型來驗(yàn)證網(wǎng)絡(luò)設(shè)計(jì)的行為是否滿足功能要求，進(jìn)而將“設(shè)計(jì)即正確”的輸出文件交付給內(nèi)部團(tuán)隊(duì)或一級合作伙伴。

接下來，可以使用 Capital VSTAR Integrator 配置AUTOSAR 基本軟件。該過程利用流程中早先的模型數(shù)據(jù)來構(gòu)造和生成已配置的軟件模板，并根據(jù)內(nèi)部規(guī)則和模型對其進(jìn)行驗(yàn)證，確保輸出準(zhǔn)備就緒。然后，在目標(biāo)硬件可用之前，可以使用 Capital VSTAR Virtualizer 虛擬運(yùn)行軟件，使得行為驗(yàn)證和調(diào)試可以在開發(fā)流程的早期進(jìn)行，節(jié)省早期樣品硬件的寶貴時間。

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

…………未完待續(xù)…………

更多詳細(xì)信息請點(diǎn)擊>>