ECU軟件
關注創建者：匿名 創建時間：2021-10-09
ECU軟件的視頻教程
ECU軟件的實例教程
<p><br></p><p><br></p><p><strong style="color: rgb(0, 50, 120);">通過XCP-on-Ethernet協議，獲取附加傳感器數據，輕松調整軟件參數</strong> </p><p><br></p><p> </p><p><br></p><p><span style="color: rgb(68, 68, 68);">隨著規模和復雜度的增加，功能軟件在汽車開發過程中扮演著越來越重要的作用。</span> <span style="color: rgb(68, 68, 68);">在現代電子控制單元（ECU）上運行的算法需要在車輛發布前進行微調并定期維護。</span> <span style="color: rgb(68, 68, 68);">ECU的微調和優化通常首先在PC上進行仿真模擬，但主要還是在試驗臺或軌道上的移動測試中進行驗證。</span> </p><p><br></p><p><span style="color: rgb(68, 68, 68);">額外的傳感器數據將提高ECU單元的洞察力，是軟件快速優化的基礎。通過添加QuantumX測量模塊，能以擴展的方式采集所有傳感器信號，涵蓋所有數據源 - 車內傳感器和總線信號數據以及附加傳感器等。</span> </p><p><br></p><p><span style="color: rgb(68, 68, 68);">使用標準化的XCP協議可將所有數據放置同一個工作流中，非常簡單和靈活。可確保了一個友好的集成測試環境，進行測量，校準和診斷（MCD），并對嵌入式軟件進行優化。
展開 為了提升開發效率、提高軟件的穩定性以及便于平臺移植，基于 AutoSar 架構開發復雜軟件已成為行業共識。
另外，行業內競爭愈發激烈，開發周期大大壓縮，加之軟件復雜度的提升，在快速迭代的情況下確保軟件質量是一個重要課題。加之 ASPICE、ISO26262 等過程體系和法規標準的要求，如何開發符合 AutoSar 架構的應用軟件、評估軟件質量和性能、優化軟件結構、驗證壓力場景下的 ECU 穩定性成為各廠商面臨的新挑戰。
本文重點介紹符合 AutoSar 架構的應用軟件開發、MBD 開發模式下的軟件質量評估與優化方案、復雜場景下的 ECU 性能壓力測試方案。
符合 AutoSar 架構的應用軟件開發介紹
對于 AutoSar 軟件架構，分為經典平臺 AutoSar CP 和自適應平臺 AutoSar AP，二者應用場景存在一定差別：AutoSar CP 具有高安全、高實時性，其通常部署在微控制器 MCU 類型芯片或多核異構芯片 M 核；AutoSar AP 具有動態性和可擴展性，適用于大數據并行處理和高性能計算等應用場景，通常部署在 MPU 或多核異構芯片 A 核。目前從行業內來看，無論是域控制器還是中央 + 區域控制器，通常都是多核的，甚至是多核異構的，不同核根據實際使用需求部署 AutoSar CP 或 AP，基礎軟件通常采用標準的 BSW 協議棧。
展開 來源 | 汽車功能安全
知圈 | 進“激光雷達社群”請加微信13636581676，備注激光
主要目錄：概述、應用層、VFB與RTE層、基礎軟件（BSW）、示例（前車燈管理系統）、總結、參考文獻
來源 | 汽車電子電氣架構創新發展論壇
它提供了在多個ECU之間分布應用程序以及集成來自不同來源的軟件模塊的可能性。
BSW進一步分為以下幾層：“服務”，“ ECU抽象”，“微控制器抽象”，運行時環境從基本軟件中提取應用程序層，并組織它們之間進行數據和信息通信。這構成了在應用程序級別上面向組件，與硬件無關的軟件結構的基礎，其中軟件模塊為獨立的單元。例如，駕駛員輔助系統的功能由軟件模塊實現。這些軟件模塊共同構成了應用程序。各個軟件模塊僅直接與RTE通信。因此，無論通信發生在ECU內還是超出ECU邊界，通信都經過清晰設計來確保獨立性，可以在不了解所使用或計劃的硬件的情況下開發軟件組件，或者在ECU之間分配現有軟件模塊。
AutoSar設計方法論
除了軟件體系結構以外，AUTOSAR還對汽車軟件的開發方法進行了標準化，從而促進了現代系列項目相關合作伙伴的合作。AUTOSAR設計方法論解決了將ECU和各種ECU中的軟件模塊集成到具有不同總線系統的車輛通信網絡中。它定義了通用工件和相關活動，尤其是活動的依賴性。該設計方法可應用于應用軟件的開發，運行時環境和系統配置中。
對于產生或可以在AUTOSAR設計方法中使用的信息，AUTOSAR定義了具有語義約束的正式數據交換格式（AUTOSAR方案）。此信息作為形式描述存儲在AUTOSAR XML（.arxml）文件中。許多工具將這些描述用于RTE和AUTOSAR BSW的配置和生成。例如，軟件組件描述為應用程序軟件提供了標準化的組件模型。或者，系統描述使用交叉鏈接的ECU實例定義系統上的純軟件層與物理系統體系結構之間的關系。它描述了網絡拓撲，每個通道的通信以及各個ECU上軟件模塊的分配。AUTOSAR設計方法的原理如下圖所示。
展開 
ECU軟件的相關專題、標簽、搜索
ECU軟件的最新內容
基于 Vector 與新思科技的開源 SIL Kit 進行系統組合，使團隊能夠快速組合并連通各個虛擬 ECU、模型和軟件組件。
預集成的廣泛生態合作伙伴技術，包括芯片模型、仿真、調試與分析工具以及軟件IP等多種資源。
標準明確規定了不同ASIL等級下必須采用的測試方法，包括：
?單元測試?：針對代碼最小單元的功能驗證，要求達到100%的MC/DC(修正條件/判定覆蓋)覆蓋率6
?靜態分析?：通過MISRA等編碼規則檢查代碼質量
?需求可追溯性?：確保每個測試用例都能追溯到具體需求
汽車ECU測試流程
傳統汽車ECU軟件測試遵循典型的V型開發流程1：
根據系統需求編寫軟件需求規格
行業對比：在與VectorCAST、LDRA等工具的對比測試中，winAMS將某ECU軟件的MC/DC達標時間從120人天縮短至68人天，且誤報率降低40%。
三、工具鏈融合：從孤島到生態的進化
3.1 與開發環境的無縫集成
嵌入式開發者常抱怨：“測試工具和IDE是兩條平行線！”
性能測試針對 ECU 電控軟件的內存（堆棧、RAM/ROM/FLASH）、CPU 負載進行最差工況的分析，保證資源占用的合理性；壓力測試構建通信、IO 驅動、診斷、網絡管理等模塊的異常注入、總線故障、高頻觸發等場景，保證軟件功能在壓力場景下不存在致命風險。
03 拓撲設計
在ECU層級，除了和傳統架構一樣進行ECU的設計以及軟件模塊的分配之外，還需要對以太網的拓撲進行設計。
面向MCU端的AUTOSAR CP平臺加密組件——Crypto
ECU中所有的軟件單元都遭受到信息安全攻擊的可能。AUTOSAR為保障ECU信息和數據安全，定義了CRYPTO 組件,包含 SecOC、KeyM、IdsM、Csm、CryIf 和Crypto Driver 等標準模塊。
更具體地說，軟件孿生技術為ECU固件的網絡安全提供了巨大的好處。有了這項技術，無論是處于開發階段的車輛，還是運營中的車隊，都可以迅速識別、評估和補救風險。Cybellum的安全套件就是這樣一個網絡安全數字孿生解決方案，用于為汽車行業創建和監控此類孿生，迎合整車廠、供應商等廠商的需求。
軟件架構及ECU系統信號
? 可針對ECU架構進行Pin腳設計，電氣參數定義，生成ICD文件
? 可針對ECU系統進行網絡設計，定義總線及報文，生成DBC文件
? 可根據網絡架構信息，繪制網絡拓撲圖
集成測試管理
? 可自定義測試用例、測試步驟、測試腳本等信息
? 可通過關聯測試用例及需求進行基于需求的測試
作為一家在汽車軟件領域擁有超過25年行業經驗的領先企業，EB為智能汽車基礎設施、人機交互（HMI）技術、導航與駕駛輔助系統、電子控制單元（ECU）以及軟件工程服務提供靈活、創新的軟件解決方案。EB的產品在全球范圍內驅動著7000多萬輛汽車。EB是大陸集團股份有限公司（Continental AG）旗下的全資子公司。
軟件或ECU質量太差，不足以支撐測試。
測試開始后，發現沒有滿足準入條件。
如果發現的bug會影響到某些測試的有效性，則這些測試要停下來。
如果修復某些bug后還需要重測某些case，則這些case在修復后再進行。
