汽車ECU的案例
汽車發動機ECU系統研發技術解析
隨著技術的進步，汽車的數字化程度越來越高。目前汽車電子信息產品已經平均占到汽車總成本的1/3，并且這個比率還在不斷提高，有專家認為，未來10年內，這個比率將達到40%。例如像寶來這樣的中檔轎車至少擁有十幾個汽車電子控制單元（ECU）。所謂ECU，實際上就是一部帶單片機的嵌入式系統，有自己的處理器、I/O設備和存儲器，能獨立控制汽車的某一系統，例如發動機管理系統EMS和ABS系統等。至于高檔轎車，往往擁有幾十個甚至上百個 ECU，這些ECU通過數字總線結構連接在一起，形成一個復雜的計算機局域網。
2 汽車ECU開發流程
汽車ECU開發流程見圖1。
2.1 汽車ECU開發的V循環方法
2.1.1 設計計算
發動機匹配項目設計計算的目的是根據汽車要求的性能確定發動機和變速器等部件的類型和參數。它分為以下3種方法。
（1）手工計算
主要是根據汽車驅動力與行使阻力的平衡圖來確定汽車在不同檔位情況下的最高車速、加速能力和爬坡能力，從而評價變速器的不同傳動比對汽車性能的影響，確定發動機和變速器的參數。這種方法計算繁瑣，結果不夠準確。
（2）仿真計算
在設計汽車和各部件模型的基礎上，輸入發動機和變速器等汽車部件和整車的性能參數，指定要求的行駛循環，最后計算出汽車的動力性、經濟性、排放性能和制動性能。它可以在計算機上顯示和打印各種分析報告和圖表結果，計算快速準確，能反映汽車系統中任何參數的變化對整車性能的影響。目前國內常見的車輛仿真商業軟件有奧地利李斯特內燃機及測試設備公司（AVLLIST GmbH）開發的汽車性能仿真分析軟件CRUISE。
（3）參數優化
將汽車的動力性、經濟性、排放性能和制動性能作為目標函數，將發動機功率、汽車重量和變速器的各檔傳動比等參數作為優化變量，在一定范圍內，尋求最優匹配組合，使汽車達到最佳性能價格比。
展開 淺談 FOTA ：通過固件方式升級汽車 ECU
例如，當汽車停在家中時，FOTA 更新可以通過 Wi-Fi 而不是蜂窩網絡執行。
行業必須制定執行更新程序的時間。例如，在完善的流程和安全措施下，ECU 在執行車輛功能時不會更新，并且只有在車輛停止移動且關閉點火鑰匙時才執行更新。
4.3經銷商所面臨的問題
隨著無線軟件更新（維護）所需的勞動力減少，經銷商逐漸失去了其主要收入來源。
此外，在初始階段，由于更新過程隨時發生，同時并非所有系統適用于 OTA 更新，所以經銷商會面臨混亂的局面。
4.4汽車原始設備制造上所面臨的難題
車輛制造商必須跟蹤每輛車的 ECU 和軟件版本，包括 ECU 之間的依賴關系。當特定 ECU 軟件更新時，必須同步更新列表。
制定正確的測試和驗證流程，從而保證車輛在軟件更新后正常運行。同時，在任何情況下，更新過程都不應影響目標 ECU重新刷新后其軟件的完整性和安全性。
構建后端基礎設施，從而通過無線方式將更新包發送到汽車端。在某些情況下，此基礎架構應連接到應用程序商店的交付系統中的客戶服務或計費系統。
結論
汽車行業正面臨著與八年前移動行業相同的經歷。隨著軟件維護需求的增大，更新汽車 ECU 已成為一項必須操作。當前軟件更新的模式成本高昂，對客戶不友好，而且不夠靈活，無法應對汽車行業正在發生的快速變化，因此，如今的汽車行業正尋找新的、更高效且更具成本效益的方法。
展開 談談汽車ECU測試
完
文章來源：汽車電子與軟件
汽車電子控制系統及其發展趨勢
但是隨著汽車電子的迅速發展，ECU的定義也發生了巨大的變化，變成了electronic control unit即電子控制單元，泛指汽車上所有電子控制系統，可以是轉向ECU，也可以是調速ECU，空調ECU等，而原來的發動機ECU有很多的公司稱之為EMS，engine
management system。隨著汽車電子自動化程度的越來越高，汽車零部件中也出現了越來越多的ECU參與其中，線路之間復雜程度也急劇增加。為了使電路簡單化，精細化，小型化，汽車電子中引進了CAN總線來解決這個問題。因為CAN總線能將車輛上多個ECU之間的信息傳遞形成一個局域網絡。有效的解決線路信息傳遞所帶來的復雜化問題。目前博世，德爾福，電裝，大陸等都是汽車ECU行業的領導者。
二、ECU的基本組成
簡單地說，ECU由微機和外圍電路組成。而微機就是在一塊芯片上集成了微處理器（CPU），存儲器和輸入／輸出接口的單元。ECU的主要部分是微機，而核心部件是CPU。輸入電路接受傳感器和其它裝置輸入的信號，對信號進行過濾處理和放大，然后轉換成一定伏特的輸入電平。從傳感器送到ECU輸入電路的信號既有模擬信號也有數字信號，輸入電路中的模／數轉換器可以將模擬信號轉換為數字信號，然后傳遞給微機。微機將上述已經預處理過的信號進行運算處理，并將處理數據送至輸出電路。輸出電路將數字信息的功率放大，有些還要還原為模擬信號，使其驅動被控的調節伺服元件工作。，例如繼電器和開關等。
展開 
汽車電控ECU功能模塊詳細介紹
ECU及控制器的搭載位置
△ 常見ECU的構成（防水型）
ECU根據在車輛內搭載的位置不同，其實際采用的形態也各種各樣。ECU的結構設計需要與其搭載環境相對應。
汽車剛開始電子化時，由于電子元件承受熱、濕度、振動等惡劣環境的能力較弱，所以將ECU搭載于環境條件較好的車室內。之后，隨著包括電路板在內的電子元件的可靠性及安裝技術的提升，ECU開始逐步搭載于環境條件較惡劣的發動機艙內，有些甚至直接安裝在發動機上。從設計層面考慮，ECU的硬件必須能夠適于安裝在車輛的任何位置，也就是“自由搭載”的概念。
另外，ECU、傳感器及執行器之間需要使用線束進行電氣連接，如果這些相互連接的線束能夠盡可能縮短，將會帶來以下益處：
① 材料費用減少，線束成本降低。
② 銅的使用量減少，為車輛輕量化做出貢獻。
③ 可減小線束的電壓，減輕供電負荷。
④ 在指定信號頻率的條件下，不易受到線束阻抗導致的感應噪聲的影響，且不易產生噪聲。
因此，有的變速器ECU搭載于變速器附近或內置于變速器。而且，控制發動機的相關電子產品直接安裝于發動機上的情況逐漸增多。點火器直接搭載于火花塞孔上，可以盡量縮短高壓線束的長度，減少點火噪聲。相反，汽油直噴發動機中驅動噴油器的EDU（ElectricDriverUnit）不但電流大，而且工作速度受到線束阻抗的制約。因此，為了盡可能縮短線束長度，ECU的搭載位置要選擇在發動機艙內且接近發動機。
△ ECU的搭載位置及形態
△ 不同搭載位置的ECU示例
展開 在阿爾瑪汽車上用modeFRONTIER for LabVIEW進行ECU系統的優化
“在基于NI CompactRio和NI LABVIEW建立的阿爾瑪汽車測試環境和ESTECO公司的優化框架之間建立的緊密集成，幫助我們快速創建兩個ECU子系統自動調節的演示。”
Enrico Corti，阿爾瑪汽車
為發動機開發和測試提供定制解決方案是阿爾瑪汽車的核心業務。公司與ESTECO合作，通過在ECU系統自動校準中應用優化技術，降低了汽車制造成本和開發時間。國家儀器公司設備的靈活性提供了對發動機和試驗設備的完全控制，而mF4LV的先進算法使他們可以快速有效地實現目標
按如下步驟建立自動調節系統的試驗環境：
●發動機和試驗臺控制器（分別連接到發動機和試驗臺傳感器/作動器），包括CompactRIO設備，用FPGA板編程及配置；
●信號從CompactRIO發送到兩臺存儲數據和設置操作參數的主機電腦。阿爾瑪汽車開發的接口提供了便捷的交互系統；
●?mf4lv運行在主機電腦連接到發動機控制器。
發動機在通過負載和旋轉速度確定的穩態工作點工作：傳感器通過CompactRIO向目標PC發送數據。mF4LV與LabVIEW共同驅動發動機控制器（比如ECU系統）以優化選定目標。
測試1 |點火提前標定以得到最大制動轉矩
挑戰
對安裝在一個測試平臺上的真實發動機的火花提前盡可能快地找到最佳校準。
解決方案
對點火提前進行控制以達到最大制動力矩（MBT）。在mF4LV中設置了點火提前角的范圍，它從缸內壓力傳感器接收信號。對信號進行處理，以得到目標并最大化（平均指示壓力，IMEP）。mF4LV使用SIMPLEX算法在10次優化迭代后得到最大扭矩。
測試2 |油膜自動動態補償
挑戰
一定比例的（x值）汽油注入到火花點火發動機的進氣歧管，在進氣道的底部沉積，當蒸發時間過去后，沉積的燃料進入到氣缸。
展開 ID.4、Model Y、Mach E電子電氣架構對比
作者 | eng2mot
來源 | 汽車ECU開發
過去我們總說：隨著汽車的功能增加，汽車中ECU的數量也越來越多，在豪華車上甚至可以達到80多個ECU。
但是在整車電子電氣架構變革的當前，汽車ECU數量會有什么變化，以及傳統車企在架構升級過程中會有哪些考慮呢？
首先
ID.4、Model Y、Mach E的ECU數量分別為52、26、51，可以明顯的看出，特斯拉的集成度高很多，這主要是因為特斯拉將眾多小型ECU的功能集成到域控制器中，比如將車門、車窗、車燈、后視鏡等的控制策略集成到LBCM LH和BCM RH中。
而福特和大眾復用了很多小型ECU
。雖然復用了不少ECU，但是大眾在電子電器架構的升級過程中，已經做了很大的更新，圖1是奧迪e-tron與ID.4的電子電器架構，可以看出巨大的變化。另外復用也是基于成本、開發時間、開發風險的權衡，還記得在ID.3剛上市時，出現了眾多軟件bug，而且ID系列與Model 3的亮相時間差不多，分別在2017、2016年，但Model 3在2017年7月就開始交付，而ID.3在2020年才開始交付。
從馬斯克的自傳中可以看出其工作節湊：
那天是周六，停車場卻停滿了車。在特斯拉的辦公室里，幾百名年輕人正在工作，有些人在電腦上設計汽車部件，另一些人則在用自己辦公桌上的電子設備做實驗。每隔幾分鐘就能聽到馬斯克爆發出響亮的笑聲，響徹整個樓層。當馬斯克走進我等候的會議室時，我對他說看到這么多人在周六上班很令人驚嘆。馬斯克卻對此不以為然，抱怨說最近周末工作的人越來越少“我們變得越來越散漫，”馬斯克回復道“我剛剛正準備發封郵件。我們太散漫了。”
展開 特斯拉最新中央計算模塊(CCM)解析
對于傳統汽車ECU而言，一個硬件平臺至少要用五六年起吧。而且還是從量產后開始算，如果從項目立項開始，那就更久了，對于傳統OEM而言，項目立項半年一年的，找供應商半年一年的。
這也是
為什么
國內
傳統OEM紛紛成立新品牌的
原因吧，
簡化
管理
，
加快
研發時間
。
另外信息娛樂系統從MCU1的英偉達，到MCU2的因特爾，再到現在的AMD，主流的芯片基本用了個遍，再結合2020年特斯拉與博通的合作消息——博通和特斯拉聯合研發的，是汽車用超大型高性能計算機芯片，將用于實現多種功能，從Autopilot自動輔助駕駛、完全自動駕駛到信息娛樂。原來英偉達，因特爾，AMD可能是過客，拿來練手的，最終還是走向自研，信息娛樂和autopilot的軟件是自研，自動駕駛的主控芯片也實現了自研，而且超算也自己做了，通過大量實車數據訓練算法也打通了，就剩信息娛樂了，打通完整的軟硬件結合了。這就有點蘋果的味道了，
對于國內新造車勢力中的第一梯隊蔚小理，誠然三者中小鵬的自動駕駛做的不賴，但是其自研的是僅僅是算法，域控制器還是采購德賽西威的，更不談信息娛樂系統。長路漫漫，不過網上也有傳聞他們在自研芯片，正在奮力追趕。
展開 CAN總線的終端電阻為什么常用120Ω？
深度分析整車控制域現狀與發展
談談對汽車OTA的理解
小鵬P7內部ECU技術信息梳理
保時捷Taycan的電子電氣架構詳解
歐陽明高院士：滑板底盤將給汽車帶來一場革命
如何寫一份牛X的汽車軟件需求
關于對汽車ECU軟件測試的理解
特斯拉最新中央計算模塊(CCM)解析
2021款特斯拉Model Y ECU接口梳理
詳解CANoe之CAPL編程
基于UDS的Bootloder詳解
關于整車上下電流程的理解
DoIP協議介紹，資料分享！
一文了解汽車嵌入式AUTOSAR架構|附下載
分享不易，懇請點個【??】和【在看】
展開 新能源汽車質量保證體系與傳統汽車單元測試規范的融合研究
標準明確規定了不同ASIL等級下必須采用的測試方法，包括：
?單元測試?：針對代碼最小單元的功能驗證，要求達到100%的MC/DC(修正條件/判定覆蓋)覆蓋率6
?靜態分析?：通過MISRA等編碼規則檢查代碼質量
?需求可追溯性?：確保每個測試用例都能追溯到具體需求
汽車ECU測試流程
傳統汽車ECU軟件測試遵循典型的V型開發流程1：
根據系統需求編寫軟件需求規格
進行軟件架構設計，確定模塊接口和數據流
實施單元測試，包括靜態測試和動態測試
進行軟件集成測試，驗證模塊間交互
執行硬件在環(HIL)測試，在實際硬件環境中驗證功能
單元測試階段通常使用Cantata、winAMS等專業工具，通過模擬(Mocking)和樁(Stubbing)技術解決外部依賴問題7。例如，對于依賴硬件接口的函數，可以創建模擬函數返回固定值，避免實際硬件不可用對測試的影響。
展開 汽車SOA架構技術要點及挑戰
現在汽車軟件圈子越來越流行‘SOA’這個概念，交流的時候不提SOA這個詞，就會顯得很不專業，是這個概念很新嗎？倒也不是，互聯網行業早已玩爛了這個概念，現在已經是micro-service甚至是serverless概念才是趨勢。那么，SOA到底是什么，為什么汽車軟件SOA才剛剛流行起來，去實現這樣一個架構，到底有多難呢？
目前主流的汽車軟件架構
現在你能在路上看到的所有車，幾乎都是這樣的架構（域架構），根據不同的功能進行劃分，各個具備各自功能的ECU相連，再通過網關進行連接，如果需要鏈接互聯網，還可以由T-Box連接移動數據（4G&5G）。
如果后期希望加什么功能，可以繼續加ECU，只要能通過CAN/LIN/Ethernet連接就行。
這個時候你可能會有一個疑問，如果這么干的話，豈不是ECU越來越多？
你的想法很對，其實現在的車輛有十幾個，幾十個，高級車甚至上百個ECU的情況都是有的，畢竟每個功能塊都有各自的任務需求，同時大部分汽車ECU的性能其實并不高，幾M的Flash，幾百K的Ram，其實都不算小了，考慮到成本與功能安全，ECU的性能夠用就行，所以ECU的數量只能越來越多。另外一個副作用就是，由于汽車ECU的數量變多，他們相互連接所用到的線束也越來越長，這也就意味著，汽車的負重更多了。（手動狗頭，更耗油了）
對于制造來說，各個OEM可以把不同的ECU交給不同的Tier1去完成，自己再去完成一個整車級別的集成，測試與驗收。這樣的分工模式也良好運行至今，你好我好大家好。
未來的潮流
現在的人們對于汽車擁有的功能，有了越來越多的期待，甚至座艙娛樂的體驗也會在很多購買汽車的年輕人當中占據非常重要的地位，而這些體驗都是需要非常之多的應用，并保持常態化更新來完成的。
展開 
結合AUTOSAR和DDS實現靈活的車輛架構
來源 |
汽車ECU開發
知圈 |
進“電子電氣群”請加微13636581676,備注架構
在消費者對自動駕駛和網聯需求的推動下，以及通信帶寬和原始計算能力的技術飛躍，汽車行業正在迅速轉型。
這些變化需要汽車設計的架構轉變，因為傳統的電氣/電子架構無法為運行未來汽車軟件系統互連系統所需的新數據中心方法提供必要的可擴展性。
AUTOSAR和DDS是兩個可以適應這些新需求的軟件標準。AUTOSAR是為汽車ecu設計的標準化汽車開放系統架構。AUTOSAR的兩個平臺AUTOSAR Classic和AUTOSAR Adaptive為不同的車輛用例提供了分層的軟件體系結構方法。特別是，AUTOSAR Adaptive平臺解決了車內高性能計算的設計挑戰，解決了下一代汽車所需的連接性和持續軟件更新。它還可以作為來自多個供應商的軟件的集成平臺。
數據分發服務 (DDS) 標準是將分布式系統的組件集成在一起的中間件協議和以數據為中心的連接框架。它通過實現低延遲數據連接、極高的可靠性和可擴展的靈活架構，使數據成為未來移動數字平臺的中心。DDS 促進了松散耦合、模塊化和開放式架構系統的開發，從而降低了復雜性、上市時間和系統成本。
為了滿足互聯數字車輛的需求，AUTOSAR 和 DDS 這兩個強大的標準現在可以協同工作。在 AUTOSAR Adaptive 平臺中，DDS 組件針對端到端數據共享進行了優化，無需自定義集成。AUTOSAR Adaptive 定義了 DDS 網絡綁定，以支持具有生產就緒通信框架的自治系統，該框架提供復雜系統所需的可靠性、可擴展性和性能。AUTOSAR 和 DDS 共同為汽車制造商提供了設計和操作下一代汽車的高性能方法。
展開 車載E/E架構不斷升級，整車架構指引趨勢
1、控制器（ECU）：功能控制核心，協助實現各項功能
功能控制中樞，處理輸入信號實現功能控制。汽車控制器是實現整車功能控制的關鍵器件，一般由MCU、電源芯片、通信芯片、輸入處理電路、輸出處理電路等構成，通過對各類傳感器信號、開關信號以及控制信號的處理，來對閥、電機、泵、開關等執行機構進行控制。
ECU架構原理圖
通過整車微控制器能夠實現的功能包括：接收信號并解析、邏輯判斷、網絡通信、故障診斷和處理、設備地址識別等等。
2、整車電子電氣功能升級，ECU數量不斷提升
微控制器在傳統的車輛中為分布式架構，每增加一個功能需要增加一個ECU。隨著整車電子電氣功能的不斷升級，ECU的數量在不斷提升。根據Strategy Analytics的數據顯示，目前汽車平均采用約25個ECU，但是高端型號ECU數量已經超過100個。不同的ECU之間，主要采用CAN/LIN總線對其進行連接，近年來汽車中CAN/LIN總線節點的數目在不斷提升，其中LIN總線節點CAGR約為17%，CAN節點的CAGR約為13%。
以數據診斷接口為中心，分布式ECU架構通過不同速率的總線系統將不同的ECU進行連接，從而實現不同的功能。
大眾汽車ECU分布圖
3、 信號復雜度+控制難度不同，控制器價值量有所區別
信號處理+輸出控制難度提升，控制器復雜度不斷升級。
展開 安波福：面向自動駕駛的衛星架構平臺
來源 | 汽車ECU開發
知圈 | 進“激光雷達社群”請加微信13636581676，備注激光
資料 | 后臺回復【安波福】獲取平臺資料
在智能化和網聯化的大趨勢下，安波福也推出了面向自動駕駛的衛星架構平臺。為了滿足OEM對自動駕駛的需求，該平臺遵循以下原則：
1、一個可持續發展的平臺：任何為未來而構建的ADAS平臺都必須使運行在其上的特性能夠隨著時間的推移而演進和擴展。OEM肯定希望避免將功能從一個平臺移植到另一個平臺，因為這可能成本高昂。他們還想確保在車輛的整個壽命期內增強ADAS功能，這意味著平臺需要具備持續的OTA功能。
2、成本效益：該平臺可以從低成本的車輛擴展到高級的車型，可以以最低的成本提供符合法規的要求，同時仍能適應與更高自動化水平相關的高級差異化功能。
3、靈活性。主動安全系統很復雜，需要高度集成。一些OEM正在尋找一種提供即裝即用的集成的全系統解決方案， 其他人則希望能夠為各個功能指定提供者，或者更好地與特定的開發環境或生態系統集成，這需要一個開放的，對開發人員友好的平臺來鼓勵創新。安波福的下一代ADAS平臺具有靈活性，可以支持這兩種方法以及兩者之間的所有方法。
基于以上的原則，安波福構建了衛星架構(如圖1所示)的ADAS平臺。在該架構下，采用不同的傳感器配置，來支持不同等級的自動駕駛（如圖2所示），例如從Level0/1升級至Level 2僅需增加個雷達傳感器和軟件適配，其他硬件不變。這樣就滿足了前面提到的OEM的成本效益要求，覆蓋從低端到高端車型的需求。
在軟件層面，不管配置如何，這些特性都運行在一個公共的、基于標準的軟件框架上，允許自動駕駛層級提升的軟件連續性。
展開 談談OEM的軟件開發
來源 |
汽車ECU開發
知圈 |
進“電子電氣群”請加微13636581676,備注架構
這兩年，由于軟件定義汽車的概念火熱，以及軟件在車輛中的價值比重越來越高，OEM如何擁抱這種變化的話題一直在被討論，下面我們就來聊聊OEM的軟件開發。
OEM其實一直承擔著部分軟件的開發，也擁有自己的軟件開發團隊，比如BMS、VCU、DCU等節點的應用層軟件基本是OEM自己開發的，但是基礎軟件和硬件是由供應商提供。
隨著OEM對應用層軟件的逐漸掌握，以及在與供應商合作的過程中想要供應商開放的越多，但供應商不想開放的矛盾逐漸加劇的情況下，OEM試圖開始自研基礎軟件和硬件。
這樣一來，首先OEM可以提升自己的軟件開發能力，培養自己的軟件開發人員；其次自主掌握控制器軟硬件的開發，應對不斷變化的需求的自由度更大，質量問題的應對也更加高效，因為只涉及內部溝通；然后由于對控制器軟硬件的掌握，在與供應商做技術交流時，可以防止被供應商忽悠；最后這也讓廠商有更多的亮點可以宣傳。
但是也有一些困難，一方面由于OEM是第一次做，在前期由于缺乏經驗積累，難免會遇到各式各樣的問題，而且有可能在量產的時候出現各式問題。
另一方面OEM是以車型項目為主導，自研與使用成熟供應商兩者之間，顯然，使用成熟供應商的產品風險更小，這就要求公司愿意承擔自研帶來的風險，并且充分相信自己的開發團隊。但是從事實來看，尤其是汽車開發與汽車生產是分開兩家公司，負責生產的公司不愿在有成熟供應商的前提下，使用全新未得到市場驗證的產品。另外車型負責人通常也不愿冒這樣風險。
這就導致做控制器開發的工程師得不到重視。
展開 