車載ECU的案例
汽車電控ECU功能模塊詳細介紹
輸入/輸出
ECU作為與外部通信的接口，為了通過微控制器運算實現符合實際狀態的最佳控制，需要檢測外部狀態的輸入手段及實際控制驅動的輸出手段。近年來為了滿足多種ECU之間密切協同控制，在ECU中還設置了通信手段。
車載ECU模塊圖
輸入電路、輸出電路、通信電路的接口方法的代表示例如下。
01
輸入接口
下圖為通過用戶進行開關操作等將ON/OFF狀態輸入至微控制器的電路示例。
開關打開時，通過鎖相電阻確定輸入電壓。在電磁干擾大等使用環境惡劣的車載ECU中，需要設置合理的濾波電路等，以防電磁干擾。其次，通過在微控制器中預裝軟件等，也可防止電磁干擾導致的異常工作。
車載環境下，存在不同電壓（蓄電池電壓、ECU內部電源的電壓）混合輸入的情況，需要對這些電源電壓進行分離處理。ECU還需要控制許多ON/OFF信號的輸入，有的會組合多種輸入信號，通過串口通信輸入至微控制器。因此，將這些控制功能集合于IC（集成電路）中，實現ECU體積小型化。
下圖為發動機冷卻水溫度、駕駛者對節氣門進行的操作等將“程度”狀態輸入至微控制器的示例。
鎖相電阻的作用是確定傳感器的輸入電壓，在傳感器斷開時也能確定輸入電壓，從而檢測出異常狀態。在ECU中，鎖相電阻具有檢測車輛異常狀態并向駕駛者發出警告的重要功能。
展開 車用電子水泵噪聲和振動特性試驗分析
電子控制單元是控制水泵的核心，與車載ECU(Electronic Control Unit，電子控制單元)建立通信，當車載ECU接收到油溫、油壓、扭矩和轉速等信號時，采用預先設定的策略給電子水泵發送一個PWM(Pulse Width Modulation，脈沖寬度調制)信號，通過PWM信號的占空比變化實現電子水泵的轉速調節。
圖1 電子水泵實物
圖2 電子水泵結構
試驗選取3種不同功率的電子水泵，不同功率的試驗泵和對標泵各選取一個，樣品1和樣品2為60W，樣品3和樣品4為90W，樣品5和樣品6為110W。其中，樣品1、4和6為對標泵，樣品2、3和5為試驗泵。
1.2 測試臺架
為了測量電子水泵的主要參數，參考行業標準設計一款車用電子水泵性能測試臺架。臺架主要由以下部分組成:平臺本體、儲水箱、測試管路、壓力傳感器和流量傳感器。臺架參數如表1所示，臺架運行流程如圖3所示，電子水泵安裝如圖4所示。
表1 車用電子水泵測試臺架參數
圖3 電子水泵測試臺架示意
圖4 電子水泵安裝布置簡圖
1.3 傳感器布置
試驗一共布置2個聲學傳感器，分別位于到電機殼中間的徑向距離20cm處和到電子水泵軸承座頂蓋的軸向距離20cm處，振動傳感器固定在電子水泵軸承座頂蓋中心位置。圖5(a)為聲學傳感器布置情況，圖5(b)為振動傳感器布置情況，電子水泵與測試臺架的進、出水管對應連接，X方向為泵的垂向方向，Y方向為泵的徑向方向，Z方向為泵的軸向方向。
圖5 測點布置示意
1.4 試驗工況設置
試驗在半消音室內進行，測試臺架放置在半消聲室內的中心位置，測試裝置必須允許最大程度上的水力循環。參考汽車水泵半消聲室噪聲測試方法，對電子水泵的振動和噪聲進行測試。
展開 智能駕駛域控制器的軟件架構及實現：軟件架構基礎及問題
比如NXP 專為雷達ECU設計的 S32R 系列，其多核心足夠同時做雷達信號處理與 L2 的功能實現。
畢竟最耗算力的視覺算法是在另外器件上完成的。
方案二單獨獨立出來 L2實現 L2 功能的控制器, 通過私有Can 與兩個 Smart Sensor 通訊獲取感知數據。一般來說，這個方案可以考慮后續增加更多的 L2 功能，如果有需要，可以再接更多的 Smart Sensor。
2.1.2 典型的軟件架構
對于采用 Smart Sensor 的系統架構來說，前向智能攝像頭和前向毫米波雷達分別給出各自觀測到的環境中目標對象的語義。這兩部分數據直接通過 Can 總線或內部的 IPC (計算機OS的進程間通訊)機制傳遞給負責感知融合和 L2 功能實現的模塊。
無論是硬件方案一還是方案二，業內最常用的軟件架構是基于 Classic AutoSar 來開發。Classic AutoSar 提供了車載ECU通用的功能并為引用軟件提供執行環境和數據輸入輸出通道。感知融合模塊和其它 ACC/AEB/LKA 功能可以實現為一個或多個 AutoSar SWC（軟件組件）。具體這些 SWC 組件是否進行拆分，如何拆分，各家開發商有自己的合理邏輯。但基本架構大同小異。
當然也可以不采用 Classic AutoSar , 用其它合適的 RTOS 作為底層系統，或許對于車載ECU需要通用功能開發和達到功能安全標準的難度會大一些，但在應用功能開發的架構體系上跟采用 Classic AutoSar 的方案沒有太大差別。
展開 五菱在海南大會的所展示的芯片和換電
這類在汽車電子應用領域較為廣泛，更多的應用在節點控制及功能稍微復雜或者對功能安全有強要求的ECU。按是否需要功能安全劃分，則可以分為非功能安全和ASIL-B及ASIL-D三種應用類別。
非功能安全的部件更多來源于車身控制和車載ECU，例如座椅，空調面板，照明燈控，Tbox,OBC，車載無線充，車載顯示屏協控制器等。
ASIL-B等級的功能安全應用更多的是汽車車身控制，例如，BCM、空調電源、電源管理，BMS,儀表盤控制、前照明大燈等；有時候非功能安全和ASIL-B的應用場景會稍微有交叉，主要看主機廠是如何做的規定。
ASIL-D功能安全的應用就屬于強功能安全應用：從汽車安全氣囊、剎車制動ABS、ESP；到電驅動、電池包BMS、變速箱和三電系統（VCU，MCU，BMS）。能夠提供D等級的MCU廠家主要有英飛凌的TC系列MCU和瑞薩的RH850系列MCU，以及NXP最新推出的S32K3系列MCU。
圖2 K32A 15x的典型應用
二、換電和圓柱電池導入的進度
五菱最讓我驚異的事情，是發布了新能源汽車智能微型換電技術和相關的換電站。
五菱智能微型換電站，由于電池小，整體的占地面積小，可以積木式擴展靈活配置多個儲電艙。換電時可通過視覺識別和激光定位技術進行精準識別，換電時間非常短。
圖3 五菱的換電站搞法
這個做法，有點像是最早之前杭州國網在康迪換電版本上做的優化。如果在微型電動汽車上做了一個車電分離，這就是類似電動自行車的搞法，真的能把電動汽車的滲透率提高5%（100萬）-10%（200萬）。
圖4 全自動微型換電站
還有一個值得注意的是，鐵鋰大圓柱在A00級別上的落地，速度很快哦，如下所示。
展開 
【新品發布】 AETP—支持TC8 v3.0的車載以太網測試套件
OPEN聯盟于5月8日正式發布了TC8車載以太網ECU測試規范3.0版本。相比2.0版本，3.0版本規范刪除了部分不適合車載環境的測試用例，并更新了2.0版本部分用例存在的描述問題。
為了可靠地解決車載以太網Layer 3-7的一致性測試問題，經緯恒潤自主開發了覆蓋TC8 v3.0 Layer 3-7全部測試用例的自動化測試套件AETP。
TC8 v3.0測試規范主要更新點
在了解AETP產品之前，不妨隨我們一起來看一下TC8 v3.0的主要更新點。
測試規范一分為三，形成TC8 v3.0 Layer 1，Layer 2，Layer 3-7三份規范。
總結來看，TC8 v3.0測試規范更加成熟，更加符合車載環境下的測試需求，對于車載以太網ECU級測試提供了更清晰的測試指導。
AETP—符合TC8 v3.0的車載以太網測試工具
AETP（Automotive Ethernet Test Package）歸屬于經緯恒潤INTEWORK產品線，是基于測試軟件INTEWORK-TAE開發的車載以太網測試套件。針對TC8 v2.0測試規范的AETP測試腳本在2019年中就已開發完成，截止目前已完成了超過50個車載以太網測試樣件的驗證。
AETP軟件界面
經緯恒潤作為OPEN聯盟成員、TC8小組聯席主席Ruetz的合作伙伴，在TC8 v3.0規范討論期間持續跟蹤更新進度。從TC8 v3.0內部成員版本公開起就著手AETP適配更新工作，并在TC8 v3.0正式版公布后進行了與TC8 v2.0版本的對比分析，調整測試腳本并完成測試驗證，完成了覆蓋TC8 v3.0規范的測試套件。
展開 汽車，需要怎樣的半導體？
用X射線觀察被稱為“Black Box（黑匣子）”的發動機ECU（Electronic Control Unit，電子控制單元，以下簡稱為“ECU”）后，可清晰地看清其內部基本結構。通過延伸到上部的金屬線（Wire）使其與外部的連接器相連接。上圖為用于摩托車的ECU，用于汽車的ECU也已實現小型化，基本結構是一樣的。（圖片出自：日本產經新聞）
就拿近期的潔凈柴油車（Clean Diesel Vehicle）而言，其模式如下：每燃燒一次，要噴射五次左右的燃料，有效使用燃料、牽出轉矩（Torque），雖然燃油量增加了，但是卻可以盡可能地排出潔凈的氣體。
雖說以毫秒為單位進行控制，但對計算機而言卻輕而易舉。其實，“工作最繁忙”的還是接收計算機信號的燃料噴射器。
汽油發動機（Gasoline Engine）也會噴射多次燃料，通過同步火花塞（Spark Plug）的點火時間和吸排氣凸輪軸鏈輪（Camshaft Sprocket），來調整配氣相位（Valve Timing）。而且，會讀取當時的車速、發動機轉數、水溫、油溫、油門開度、駕駛員腳踩加速踏板的程度（加速度），來判斷駕駛員的加速要求、進行必要的控制。
此外，還通過與變速箱進行良好的配合，順利實現省油效果。想必很多讀者會認為，需要一款高性能的計算機才可以實現以上效果。但是，由于ECU是車載專用控制單元，因此與當下的計算機相比，其計算能力并不是那么高。
不僅只有ECU才使用半導體，幾乎所有的電子零部件都需要半導體。
展開 MCU的內存如何影響區域和域控架構
為了滿足用戶對舒適度、安全性和自動駕駛功能的需求，車載ECU(電子控制單元)的數量不斷增加。然而ECU數量的增加也給汽車制造商帶來了更多挑戰。因此，全球大多數汽車制造商正在從傳統的分布式 ECU 架構過渡到基于域或區域的 ECU 架構。
在分布式的架構中，所有的功能緊密交互，難以管理系統的復雜性和實時性，域控架構目的是將分散的控制鏈路，整合到單個大型ECU中(如圖1所示)。例如將在新能源車上，將整車控制器、電池管理系統、電機控制器整合至一個控制器中。
圖1 域控架構
區域(Zonal)架構是將來自多個域的多個ECU 進行整合，并減少整車線束的數量(如圖2所示)，線束數量的減少有望降低車輛的重量和線束的復雜性，重量的降低可以提升純電車型的續航里程。對于車輛中眾多的ECU，可以根據實際情況，選擇使用域架構還是區域架構，充分利用兩種架構的優勢。
圖2 區域架構
區域和域架構都支持硬件和軟件生命周期的分離。兩者都允許汽車制造商在不更改組件的情況下更新和升級車輛軟件。這些新架構還支持軟件定義汽車概念，可以在最短的時間內推出新的功能和車型。
內存需求的變化
首先，與傳統分布式架構中使用的MCU相比，域和區域架構需要提供更高計算能力的 MCU。當前域架構中需要主頻為400MHz的多核實時MCU。符合這種條件的MCU有的具有多達6個Arm Cortex-R52 內核或者Tricore內核，其中多達 4 個內核以鎖步配置運行，以執行實時錯誤檢查。
盡管 MCU 內核和工作頻率是系統架構師常用的參考規格，但非易失性存儲器 (NVM) 也對整體系統性能和成本產生重大影響。
展開 SOA=SOME/IP？你低估了這件事 | 第二彈
正如大家所知道的，目前CP在各類車載ECU的開發實現中占有很大的使用比例，主要是應對嵌入式ECU的開發，這很符合之前我們聊到的一個盒子一個功能的整車分布式EE架構的需求，具體功能后可以精準的控制ECU本身的軟硬件開發，并且CP軟件架構的模塊化方式配合AUTOSAR OS也可以充分滿足一些特定功能對ECU本身運行時實時性要求。
隨著架構的智能網聯化發展，要求一些節點具備處理海量數據和執行大規模高頻次算例的能力，這就會要求此類節點具備豐富的軟硬件資源，同時滿足車載環境下安全性的要求。該背景下，擅長用于嵌入式ECU的CP就顯得心有余而力不足了。
當然普通的OS同樣也滿足不了這一需求，例如Android，某些場景下它不能滿足車載功能安全需求。此時AP登上歷史舞臺，作為HPC（High Performance Controller）類型ECU的重要組成部分，AP所做就是統一管理下屬OS以及周邊資源，使得系統運行時的一切調度、狀態和資源消耗處在一個可控的范圍內，以滿足車載安全性的要求。當資源豐富時，可選擇的余地就大些，比如可以充分利用多核異構架構來處理復雜場景，使用Hypervisor等虛擬機技術，使CP、AP和非AUTOSAR系統共同存在于HPC中，也算是一種典型的實現方法，當然一切從需求出發。
進度條撐又不住了，本次的分享先告一段落，第三彈，我們聚焦于各大OEM，看看他們是如何實現自己的SOA，我們下期再見~~
展開 MCU的內存如何影響區域和域控架構
為了滿足用戶對舒適度、安全性和自動駕駛功能的需求，車載ECU(電子控制單元)的數量不斷增加。然而ECU數量的增加也給汽車制造商帶來了更多挑戰。因此，全球大多數汽車制造商正在從傳統的分布式 ECU 架構過渡到基于域或區域的 ECU 架構。
在分布式的架構中，所有的功能緊密交互，難以管理系統的復雜性和實時性，域控架構目的是將分散的控制鏈路，整合到單個大型ECU中(如圖1所示)。例如將在新能源車上，將整車控制器、電池管理系統、電機控制器整合至一個控制器中。
圖1 域控架構
區域(Zonal)架構是將來自多個域的多個ECU 進行整合，并減少整車線束的數量(如圖2所示)，線束數量的減少有望降低車輛的重量和線束的復雜性，重量的降低可以提升純電車型的續航里程。對于車輛中眾多的ECU，可以根據實際情況，選擇使用域架構還是區域架構，充分利用兩種架構的優勢。
圖2 區域架構
區域和域架構都支持硬件和軟件生命周期的分離。兩者都允許汽車制造商在不更改組件的情況下更新和升級車輛軟件。這些新架構還支持軟件定義汽車概念，可以在最短的時間內推出新的功能和車型。
內存需求的變化
首先，與傳統分布式架構中使用的MCU相比，域和區域架構需要提供更高計算能力的 MCU。當前域架構中需要主頻為400MHz的多核實時MCU。符合這種條件的MCU有的具有多達6個Arm Cortex-R52 內核或者Tricore內核，其中多達 4 個內核以鎖步配置運行，以執行實時錯誤檢查。
盡管 MCU 內核和工作頻率是系統架構師常用的參考規格，但非易失性存儲器 (NVM) 也對整體系統性能和成本產生重大影響。盡管如此，NVM的規格是最容易被忽視的。例如，兩個具有相同內核和工作頻率的 MCU 在計算性能、功耗以及可靠性方面可能會因其使用的NVM類型和讀寫速度而存在顯著差異。
展開 車載以太網的未來：OPEN Alliance下17個技術委員會的最新進展與行業影響（上）
TC8 Automotive Ethernet ECU Test Specification （on hold）
TC8負責制定車載以太網ECU測試要求，定義基于這些要求的車載以太網中所有ECUs的測試規范。不僅如此，TC8還負責定義測試過程，支持可執行ECU測試的實驗室的建立，定期審核測試規范，以提高車載以太網ECU和網絡的通信質量。
2023年，TC8與聯盟內的其技術委員會如TC9/12和TC14緊密合作，討論改編針對1000BASE-T1和10BASE-T1的物理層一致性測試規范（IOP和PMA）。同時，TC8也在密切關注IPv6協議一致性的需求，積極收集測試用例，進行技術審查，特別是針對汽車適用性方面，預計這項工作將需要更多TC8成員的參與以達到啟動項目所需的臨界數量。
按照計劃，2024年的第一季度TC8將發布針對1000BASE-T1和10BASE-T1的一致性測試規范。
截止目前，TC8發布的最新規范見下表。
OPEN聯盟TC9-TC17的目標與2023年的重要進展將會在下篇為大家介紹，敬請期待。
經緯恒潤作為OPEN聯盟會員和AUTOSAR聯盟的高級合作伙伴，長期為國內外各大OEM和供應商提供涵蓋TCP/IP、SOME/IP、DoIP、AVB、TSN、DDS等技術領域的設計和測試咨詢服務，積極研發和探索車載網絡前沿技術的工程應用。通過多個項目的實踐經驗，已建立了高質量、本土化的設計與測試一體化解決方案，為整車網絡架構提供可靠支持。
了解更多：請致電 010-64840808轉6117或發郵件至market_dept@hirain.com（聯系時請說明來自技術鄰）
展開 車載以太網一致性測試套件INTEWORK-TAE AETP
概述
致力于車載以太網ECU級協議一致性測試，經緯恒潤自主研發了自動化測試套件AETP（Automotive Ethernet Test Package）。AETP歸屬于經緯恒潤INTEWORK產品線，基于自研測試軟件INTEWORK-TAE開發。
覆蓋全面的車載以太網輕量化測試工具
AETP目前覆蓋車載以太網以下測試內容，可歸為TC8標準測試和主機廠自定義測試兩類（診斷、AVB、系統通信）：
AETP的Layer 3-7測試不需要復雜硬件配合使用（網關路由例外），避免了外接測試設備不便移動的問題，降低了價格成本。Layer 1的TC8百兆/千兆物理層IOP測試，需配合經緯恒潤自研的TESTBASE-EIOP測試設備使用。
測試系統由PC、Converter（通用轉換設備）、AETP測試套件及測試線纜組成。PC安裝有AETP測試套件，測試套件調用PC的有線網卡發送和接收測試數據。通過Converter實現PC與DUT的100/1000Base-T1的物理層協議轉換。
便捷的測試執行
TC8等測試規范中定義了大量的測試輸入參數，需要充分理解測試用例才能明確具體含義和配置方式。開發人員基于豐富測試經驗，優化了測試參數配置，有效地降低了測試難度。
用戶完成參數配置后，選擇并運行單項測試用例或者測試用例組，即可自動完成對應測試并生成測試報告。
豐富的測試結果展示
測試報告可根據需求生成多種格式。AETP測試報告詳細上傳了每一步驟的期望結果與實際測試結果。如果某個測試用例樣件測試失敗，通過測試報告能夠清晰判斷該測試用例通過的要求以及失敗的原因，幫助測試人員快速明確問題點。
展開 
英特佩斯總線采集測試仿真工具
RAD-Galaxy 車載以太網的多路動態探測與網關工具
英特佩斯的RAD-Galaxy是一款在汽車以太網應用中的多用途以太網介質轉換器和多路動態檢測工具。使用汽車以太網，您可以監控至多6路雙端BroadR-Reach?(100BASE-T1)連接，或者將您的筆記本電腦連接到多達12路BroadR-Reach?ECU或其他設備上。
RAD-Galaxy有12個BroadR-Reach?(100BASE-T1)的PHY，它可以支持8x CAN FD通道，4 LIN通道，DoIP功能，以及脫機運行模式。
? 功能特性
? 以亞微秒的時延動態探測主從節點間的全雙工通信數據
? 具有基本的過濾和路有能力
? 可作為BroadR-Reach?至千兆以太網橋接設備
? 支持時間協議（PTP）
? 支持音頻視頻橋協議（av B）
? 包含Vehicle Spy 3的License
? 應用
? ECU級和系統級別的自動測試
? 車載以太網通訊監控
? 網絡仿真/總線仿真
? 車載以太網到CAN FD或LIN的網關應用
? 數據采集功能
? 基于CAN FD或車載以太網的多節點刷寫功能
? 系統級/網關ECU測試
RAD-Galaxy擁有的特性使其可以測試一個由多達6個連接到車載以太網網關的ECUs/節點組成的系統，以及8路CAN FD網絡。使其成為網關ECU測試以及系統測試的理想測試工具。
展開 從汽車芯片短缺開始說起
32位MCU在汽車電子應用領域較為廣泛，更多的應用在節點控制及功能稍微復雜或者功能安全有強要求的ECU；隨著部分功能的需求提升，部分使用8位MCU的末端ECU為了提升用戶的體驗感和豐富功能，也進行了MCU的處理性能升級，升級到了32位MCU；例如座椅；如果單純的3電機6相控制，單純實現功能8位就可以滿足，但是為了增加體驗感，例如增加記憶、通風加熱、增加診斷和bootloader功能，原來的8位不夠了，進而升級到32位MCU；如果從是否需要功能安全劃分則可以分為非功能安全和ASIL-B及ASIL-D三種應用類別。
非功能安全的部件更多來源于車身控制和車載ECU，例如座椅，空調面板，照明燈控，Tbox,OBC，車載無線充，車載顯示屏協控制器等。這部分有的KEA系列32位MCU，瑞薩傳統系列的MCU，也有采用S32K1系列的具備ASIL-B功能安全等級的MCU。
ASIL-B等級的功能安全應用更多的是汽車車身控制，例如，BCM、空調電源、電源管理等；有時候非功能安全和ASIL-B的應用場景會稍微有交叉，主要看主機廠是如何做的規定。目前可以提供真正ASIL-B等級的MCU品牌廠家不多，主要是NXP的MCU。
ASIL-D功能安全的應用就屬于強功能安全應用；從汽車安全氣囊、剎車制動ABS;ESP；電驅動；電池包BMS、變速箱和三電系統（VCU，MCU，BMS）；能夠提供D等級的MCU廠家主要有英飛凌和瑞薩及NXP；
在國內真正能可靠導入的，主要落實在按照ASIL-B等級的要求進行設計，還需要時間通過功能安全認證，在這個領域是需要依靠比較長的時間積累的。
展開 以太網物理層IOP測試設備TESTBASE-EIOP
為了保證各個供應商之間的控制器能夠互聯互通，OPEN 聯盟TC8工作組致力于100BASE-T1和1000BASE-T1車載以太網ECU測試規范的開發，相應的規范《OPEN Alliance Automotive Ethernet ECU Test Specification Layer 1》已于2020年初更新到3.0版本。同時，《OPEN Alliance Automotive Ethernet ECU Test Specification Layer 1 1000BASE-T1》 V1.0版本也于2020年初釋放。
TESTBASE-EIOP是經緯恒潤自主研發的車載以太網物理層IOP（交互性）自動化測試設備，可完整覆蓋OPEN TC8 IOP測試標準。
展開 Intrepid—總線采集測試仿真工具
媒介轉換器模式
RAD-Galaxy可以被設置成媒介轉換器來工作，可使其與至多12個車載以太網ECU進行交互。這樣可以使用戶能夠進行節點模擬，或直接操作診斷和ECU刷寫功能。
