基于虛擬平臺的電動汽車的虛擬設計和驗證解決方案

　　集成系統(tǒng)時的一個大挑戰(zhàn)就是零配件總是不變地來自多家供應商，這使得安全性和質(zhì)量打了折扣。在開始ECU-軟件集成時，可能出現(xiàn)數(shù)千個錯誤。人們越晚發(fā)現(xiàn)這些問題，解決這些問題的代價就越高。而一旦問題在汽車已交到顧客手中時才顯露出來，修復就變得非常昂貴。《商業(yè)周刊》曾報道豐田在2009至2010年的召回，使公司損失超過20億美元，包括法律費用、銷售損失和保修支付。

　　系統(tǒng)工程和仿真

　　那么伴隨著車輛的電氣化，汽車設計團隊如何能夠征服系統(tǒng)設計挑戰(zhàn)呢？這個問題的著眼點不只限于軟件和電子設備——設計團隊還必須考慮機電系統(tǒng)?？赡艿慕鉀Q方案需要支持詳細的物理建模，概念性設計和實現(xiàn)，以及并行的、多層次的建模和驗證。

　　汽車電子的歷史已經(jīng)從簡單的發(fā)電和送電，經(jīng)過電子控制系統(tǒng)，演進到電子駕駛系統(tǒng)。電子部件所占成本的比例已經(jīng)從10%增加到電子混合動力汽車的60%。成本不是在軟件（軟件的制造幾乎是免費的），而是構成車輛的電子、電氣和機電組件。

　　基于模型的嵌入式系統(tǒng)工程

　　汽車制造商因為多種目的而需要模型：

　　● 分析/驗證產(chǎn)品的需要；

　　● 為電子工程系統(tǒng)定義軟件應用；

　　● 支持仿真和驗證工廠/多物理/汽車系統(tǒng)模型。

　　因此，建模需要使用多種不同的框架：

　　● AUTOSAR——運行在一個虛擬處理器上的軟件；

　　● EAST-ADL2——運行在一個環(huán)境（包括工廠）中的軟件；

　　● VHDL-AMS/MAST——機電一體化建模和電氣系統(tǒng)；

　　● SystemC/SystemC-AMS——各種系統(tǒng)級芯片（SoC）的系統(tǒng)級描述和相互連接；

　　● SystemVerilog/Verilog-AMS——SoC實現(xiàn)，以及SPICE—IC模擬。

　　將所有這些元素匯集在一起需要一個能夠建模和進行物理系統(tǒng)仿真的平臺，它支撐了整個系統(tǒng)的虛擬原型驗證，可用于模擬/電力電子，電力產(chǎn)生、轉(zhuǎn)換、輸送和機電一體化等應用（如圖1所示）。

圖1 系統(tǒng)級的物理建模和仿真

發(fā)電、管理和輸送

　　車輛的核心功能依然是電力的產(chǎn)生、管理和消耗。隨著電氣化的程度提高，這個趨勢則益發(fā)明顯，因為發(fā)電機現(xiàn)已成為所有這些領域的一個因素。所有的電氣系統(tǒng)需要利用低功耗技術，以使車輛的耗電量能夠減少，同樣也縮小電池的大小。

　　我們能夠通過優(yōu)化12/24/48V負載，減少車輛中的電線數(shù)量，并且設計更有效率的HVAC暖通空調(diào)（采暖，通風和空調(diào)）系統(tǒng)，來降低電池上的電力負載。

　　與汽車相比，其他諸如手機行業(yè)等領域擁有多得多的應用低功耗技術的經(jīng)驗。電池巡航時間在決定像Android那樣的移動軟件平臺的成功與否上扮演了重要角色。反過來，軟件在決定電池巡航時間時也發(fā)揮著很大作用。例如，一項僅為8秒鐘的更新而每10分鐘喚醒電話的應用，能夠?qū)⑺拇龣C時間減半。任何功率效率低下的軟件或故障可以迅速導致其待機時間縮短5倍或更多。

　　用于節(jié)能和能源管理的、復雜的而高度分散的軟件實體必須被垂直化整合和相互協(xié)作，以確保高效地使用手機里的電池。手機的使用場景扮演了一個重要的角色，因為它們定義了手機如何與環(huán)境進行交互。但是，當手機被鎖住放在你的口袋里時，你怎么能去為你的手機糾錯？你怎么能確保場景都是確定匹配不同實現(xiàn)選項？

　　為功率類缺陷除錯帶來另一個重要問題。在諸如“暫停”這樣的低功耗模式中，嵌入式系統(tǒng)的除錯服務可能也被暫停了。此外，與設備的任何除錯互動都是侵入性的并嚴重地損害功率數(shù)據(jù)。進一步來說，如果去實施足夠精細的粒性功率分析來甄別哪個元器件最為關鍵，就需要使用昂貴的實驗設備。

　　設計師所面臨的各項挑戰(zhàn)在很多方向上都正在融合，不論他們設計的是手機抑或是電動汽車。