
張可晨 楊金升 唐新宇
本書遵循由淺入深的原則,將內容分爲三篇。基礎篇首先介紹車載網絡的相關知識,接着介紹CANoe開發環境和常見功能的使用,以便初學者掌握使用CANoe進行一般的總線仿真、測試和分析的方法;入門篇首先介紹CANoe開發總線仿真的基礎知識,接着結合實例重點介紹總線數據庫創建、面板設計,以及CAPL語言設計;進階篇結合廣大開發工程師可能面臨的技術難題,由簡單到複雜地介紹一些典型實例,以提高讀者的實戰技術。
2020年第n本書,匆匆讀過。之後有時間再讀。
入門的話確實還行,概念大概都弄清楚了。
當入門指引還行,還不如官方幫助文檔好使
本書包含了Canoe各功能菜單的具體說明,可以作爲工具書參考使用,要結合Canoe軟件操作學習更好一些,Canoe相關學習書籍很少,該書值得推薦
CAN OE入門非常不錯的一本書,總結如下: 車載網絡基本知識。 CANoe基本知識。 CANoe基本功能操作。 仿真 診斷 測試 分析 發生器 CAPL語言設計 汽車診斷技術基本知識 UDS,OBD CANoe工程實例。 CANoe高級編程聯合。 python labview #### 1.1 車載網絡起源 **。目前常見的ECU有: ABS(防抱死系統)、 EBD(制動力分配系統)、 EMS(引擎管理系統)、 多功能數字化儀表、 主動懸架、 導航娛樂系統、 電子防盜系統和自動空調等** #### 1.2 CAN總線概述 **CAN(Controller Area Network,控制器局域網絡)屬於工業現場總線的範疇** **1993年,CAN成爲國際標準ISO 11898(高速應用)和ISO 11519(低速應用)。** **CAN總線是一種串行數據通信協議,其通信接口中集成了CAN協議的物理層和數據鏈路層功能,可完成對通信數據的成幀處理,包括位填充、數據塊編碼、循環冗餘檢驗、優先級判別等工作** **實現單根電纜串接全部設備,節省安裝維護開銷;提高實時性,信息可** **CAN-FD總線彌補了CAN總線帶寬和數據場長度的制約。** #### 1.3 LIN總線概述 **LIN(Local Interconnect Network,局域互聯網絡)是專門爲汽車開發的一種低成本串行通信網絡,是對現有汽車多元化網絡的一個補充** **典型的LIN總線應用是汽車中的聯合裝配單元,例如,門、方向盤、座椅、空調、照明、溼度傳感器和交流發電機等。** #### 1.4 目前典型車載網絡架構 **高端車型中的ECU因功能複雜以及數據交換量大,對總線的要求也比較高,除了上述介紹的CAN總線以及LIN總線外,還可能包括MOST(Media Oriented System Transport,媒體導向的串行傳輸)、FlexRay和Ethernet等總線** **與緊湊型總線架構的主要區別是使用了MOST環和複雜的Gateway(網關),實現了多媒體數據的快速傳輸,例如,可以實現將導航娛樂系統的地圖或者MP3的封面輕鬆地傳輸給儀表盤(一般帶有7英寸以上的TFT)。但由於Ethernet(以太網)總線相對MOST總線更加穩定和經濟,目前在開發的很多豪華車型已經開始使用Ethernet代替MOST。** #### 2.1 關於Vector公司 **CAN總線分析工具—— CANalyzer** **增加總線仿真等功能,公司開發出第一版CANoe** #### 2.2 CANoe簡介 **最初主要爲汽車CAN總線的開發、仿真、測試和分析而設計** #### 2.3 CANoe在ECU項目開發中的作用 **在開發的初期階段,CANoe可以用於建立仿真模型,在此基礎上進行ECU的功能評估,這樣就可以儘早地發現問題並解決問** **在這個階段,CANoe主要充當網絡系統分析、測試和診斷的工具。** #### 2.4 CANoe不同版本的區別 **CANoe run版本爲CANoe的運行版,支持CANoe的大部分功能,在項目中應用比較廣泛。** **Demo版本的最根本限制是無法連接和操作硬件接口,其他限制還有如下幾個方面。** #### 3.2 CANoe選項卡和功能區 **CANoe主界面主要有以下功能區部分。· File(文件)· Home(主功能區)· Analysis(分析)· Simulation(仿真)· Test(測試)· Diagnostics(診斷)· Environment(環境)· Hardware(硬件)· Tools(工具)· Layout(佈局)** #### 3.3 常用仿真窗口 **總線仿真是CANoe的最重要功能之一** #### 3.4 常見診斷窗口 **CANoe可以支持強大的診斷功能** #### 3.5 常見測試窗口 **CANoe提供了Test Unit(測試單元)和Test Module(測試模塊)以實現自動化的測試** #### 4.1 CANoe總線測量和分析概述 **CANoe的測量和分析是基於數據流方向的,從數據源到處理數據、顯示數據和記錄數據,數據可以根據需要被單獨處理。** **:爲了便於後續的數據分析,測量數據可以按時序先後記錄到Logging文件中** #### 4.3 常見分析窗口 **CANoe提供多種分析窗口,用戶可以根據需要對數據進行圖形化分析、統計、對比、過濾和保存等,有些分析窗口還提供個性化設** **Trace(追蹤)窗口主要用於記錄和顯示測量過程中的所有活動,包括收發報文、錯誤幀、系統變量、環境變量和診斷服務等,如圖4.7所示** **Statistics(統計)窗口用於統計Measurement Setup窗口運行過程中的總線(CAN、LIN、FlexRay等)活動,可以在Measurement Setup窗口中插入Statistics功能。** #### 4.6 發生器模塊 **發生器模塊爲用戶提供了一種便捷高效的方式發送報文,使用起來非常靈活。該模塊主要應用在網絡架構相對簡單或用戶需要自定義觸發行爲的場合。** #### 5.1 配置仿真工程 **誤將虛擬通道映射到邏輯通道,如圖5.8所示。** **虛擬CAN通道,顧名思義,是虛擬了一個物理的通道,它擁有與物理通道相似的功能,但不會通過硬件將CAN報文發送到真實總線上** #### 5.2 不同版本工程文件之間的兼容性處理 **如果用戶B只有低版本的CANoe,那麼就需要用戶A在保存所創建的CANoe工程的時候選擇適用於用戶B的版本** #### 5.3 仿真工程個性化設置 **用戶可以根據每種測試場景配置爲不同的工程文件,這樣可以減少用戶配置環境的時間。例如某仿真工程爲Project_A_CAN_Simulation,則用於臺架測試的工程文件可以保存爲Project_A_CAN_Simulation_BenchTest.cfg,用於實車測試的工程文件可以保存爲Project_A_CAN_Simulation_InCarTest.cfg。** #### 5.4 仿真工程文件夾的命名習慣 **一般來說,最常見的文件夾是 CANdb、 Nodes、 Panels和 Logging等** #### 6.1 ECU硬件/軟件架構介紹 **Electronic Control Unit,即電子控制單元(有時也被簡稱爲電控單元** #### 6.2 開發仿真工程的必要性 **RAD(Rap Application Development,快速應用開發)模型是軟件開發過程中的一個重要模型,由於其模型形似字母V,所以又稱爲軟件開發的V模型,** **在這個階段,不管從成本角度還是效率角度考慮,用戶都需要一種仿真工具模擬其他ECU模塊的功能,這樣可以大大加快開發進度,縮短驗證週期** #### 7.1 創建第一個仿真工程 **CANdb、Panels和Nodes** #### 8.1 總線數據庫概述 **CAN總線數據庫格式是DBC文件,已成爲行業內的標準文檔格式** ### 第9章 Panel設計 **CANoe的仿真環境之所以深受廣大用戶的歡迎,其中一個主要原因是其支持非常直觀的圖形化仿真Panel(面板)功能** ### 第10章 CAPL語言設計 **CAPL既能夠通過編程實現節點的仿真,也可以在數據分析、測試等方面發揮很大的作用,通過與外界系統的交互,實現仿真、診斷和測試的自動化。** #### 10.1 CAPL概述 **CAPL全稱爲Communication Access Programming Language,即通信訪問編程語言** **CAPL可以說是CANoe的靈魂,使CANoe滿足仿真、分析、測試和診斷的各種複雜的要求,同時使CANoe的功能得以不斷擴展** #### 10.3 CAPL基礎——數據類型 **報文(CAN/LIN messages)是車載網絡最基本的構成部分,CAPL提供了各種網絡相對應的報文類。這裏主要介紹CAN報文和LIN報文。** #### 10.6 CAPL基礎——程序結構 **一個完整的CAPL程序由4部分組成:頭文件include files、全局變量聲明、事件處理和自定義函數。** #### 13.4 擴展話題——關於網絡管理 **網絡管理(Network Management, NM)被逐漸應用到汽車ECU單元中。對於引擎關閉後並不立即關閉的ECU單元(如儀表、主機、座椅調節單元等),網絡管理顯得尤爲重要。網絡管理爲這些ECU單元建立了睡眠、喚醒和掛起的機制,保證了通信的可靠性以及整車系統的休眠功耗。** #### 14.4 測試單元與測試模塊簡介 **CANoe提供了測試單元和測試模塊兩種方式,兩者均爲面向事件的順序執行模式** #### 15.1 汽車診斷技術概述 **OBD(On-Board Diagnostic)車載診斷系統,最初起源於CARB(California AirResources Board,加州空氣資源委員會)爲1988年之後生產的加州汽車所制定的排放法規** **本節將着重介紹增強型診斷中的UDS診斷協議** **UDS只定義了應用層的診斷協議和服務** #### 15.2 CANoe診斷功能簡介 **通常CDD文件由整車廠或ECU軟件開發人員提供** #### 15.5 工程實現 **需要指出的是,讀者需要參考CDD文件來確定每個診斷請求的會話模式及安全訪問權限,例如,面板中的Vehicle Identification Number(VIN,車架號)的讀寫操作需要在指定的會話模式和安全訪問等級下才能操作。** #### 15.6 工程運行測試 **CAPL診斷測試模塊的執行,相對比較簡單,單擊Diag_Session&VIN測試模塊開始按鈕即可,執行結果如圖15.18所示** #### 23.6 擴展話題——LabVIEW調用CANoe **LabVIEW調用CANoe的需求相對比較多。這樣的需求可以通過LabVIEW調用CANoe COM Server來實現**
乍一看內容很多,仔細一看啥也沒有。
非常全面的ECU仿真開發書籍 對工作中常用場景有一定科普意義
作爲新手入門讀物,前2章知識點掃盲作用比較大,後面涉及代碼、頁面操作基本看不懂,但也跳讀看完了,實踐中遇到有可能再回頭精讀理解。工具書,活用則受用。
汽車行業必備,愛了。相當詳細基礎,看完就能簡單做工作了。