如何解決(jue) 當前CAN網絡應用層協議設計麵臨(lin) 的關(guan) 鍵問題？

就如同集成電路、微處理器的誕生一樣，數據總線技術的問世成為(wei) 了汽車電子技術發展的一個(ge) 重要裏程碑。如今，隨著CAN總線技術在汽車電子領域日益廣泛的應用，其協議一致規範表述的重要性也逐漸凸現。根據ISO（國際標準化組織）定義(yi) 的OSI模型，CAN協議定義(yi) 了物理層及數據鏈路層規範，為(wei) 不同的汽車廠商製定符合自身需要的應用層協議提供了便利。如果需要建立更加完善的係統，還需要在CAN的基礎上選擇合適的應用層協議。

為(wei) 了幫助業(ye) 內(nei) 工程師進一步了解汽車CAN網絡應用層協議製定的重要性，以及掌握汽車CAN網絡應用層協議設計技術，並解決(jue) 其關(guan) 鍵問題，在電子工程專(zhuan) 輯旗下的汽車電子設計網站舉(ju) 行的《如何解決(jue) 當前CAN網絡應用層協議設計麵臨(lin) 的關(guan) 鍵問題？ 》專(zhuan) 題討論中，Mentor Graphics資深產(chan) 品專(zhuan) 員董因平博士應邀與(yu) 工程師進行互動，與(yu) 大家進一步探討了汽車CAN網絡應用層協議製定方麵的話題。基於(yu) 此次專(zhuan) 題討論，我們(men) 總結了汽車CAN網絡應用層協議設計中經常出現的一些問題供讀者參考。

解析CAN協議應用層與(yu) 應用程序

董因平博士表示，應用層和應用程序是不一樣的。應用層是指通訊功能的應用層。它並不定義(yi) 和描述應用程序參數，它提供的隻是通訊功能與(yu) 應用程序的通訊接口。包括：定義(yi) 通訊服務、傳(chuan) 送過程數據、診斷信息及標定信息。設備監控和網絡管理也一般定義(yi) 為(wei) 應用層的一部分，有的也將傳(chuan) 輸層的部分內(nei) 容納入應用層實現，比如超過8個(ge) 字節的數據傳(chuan) 輸。

應用程序就完全是指控製算法等應用代碼。它定義(yi) 控製算法相關(guan) 的數據和參數。

在目前ECU開發中，應用程序代碼包含了應用層代碼。其缺點在於(yu) 以下三個(ge) 方麵：

1. 應用程序發生變化，必須考查應用層是否還能滿足要求。

2. 通訊協議發生變化，整個(ge) 應用程序及應用層代碼都必須重新編譯測試。這個(ge) 問題是造成整車廠在協議開發中不能起主導作用的主要原因之一。所以有很多國內(nei) 的整車廠有了新的協議，希望某些國外大型供應商實施新協議時會(hui) 遇到極大的阻礙。一是不願意做，二是重新開發的費用高昂。

3. 嚴(yan) 重阻礙了節點和設計的重用。由於(yu) 應用程序和應用層融合在一起，難以實現即插即用的效果。

解決(jue) 方案就是接口標準化，即將應用層從(cong) 應用程序中分割出路並標準化接口。 AUTOSAR的一個(ge) 特性就是標準化接口，實現即插即用。Mentor Graphics的VTP也是一個(ge) 典型的例子。

CAN測試重要還是協議製定重要？

董因平博士表示，測試和設計的重要性在不同設計思路中有不同的體(ti) 現。目前應用層協議製定的方法可以分為(wei) 兩(liang) 大類，一類是測試為(wei) 重心的方法，一類是設計為(wei) 重心的方法。

第一種方法也稱為(wei) 投票法或試驗法。這是一種工程設計方法，各個(ge) 供應商對協議提出要求，整車廠集成要求，通過測試驗證協議可行性，隨後發布協議。測試的功能除了驗證協議的實現外，還有一個(ge) 重要的任務就是對協議設計進行測試，試圖解決(jue) ID分配不合理、消息衝(chong) 突問題等等。這種方法的重心就是測試，因此測試比較重要。

第二種方法是係統級設計法。這是一種理論設計方法，它提出了完全不同的需求，供應商隻需要提供相應的參數，根據一定的理論模型對網絡通訊特性進行計算，如信號延遲、總線負載等。以此為(wei) 基礎，考慮設計需求，通過一定的調度算法，對每條消息的ID進行分配。方法的核心就是優(you) 化這些特性參數，保證整車網絡通訊的實時性能。因此在這種設計方法中，設計是重點。

董因平博士還指出，測試並不等同於(yu) 驗證。他說：驗證表示的是我們(men) 有一個(ge) 標準，測試被測對象是否符合。但是目前汽車電子的測試不能一概的稱為(wei) 驗證，因為(wei) 它還要測試協議設計是否正確，協議設計中是否有瑕疵。驗證的輸入是被測對象的特性，參照的是標準，輸出的是兩(liang) 者是否符合。

而現在的測試，輸入的既有被測對象的特性，又有所謂的標準，輸出的是協議是否需要修改、係統是否可行、設計是否符合需要。注意這裏引出了一個(ge) 難以讓人理解的地方，我們(men) 要測試ECU是否符合標準，但是我們(men) 卻又在根據測試結果在懷疑這個(ge) 標準。因此除非有非常雄厚的技術和經驗積累，否則你始終在這兩(liang) 者之間徘徊，浪費時間和金錢。中國目前就處於(yu) 這種狀態，但是我們(men) 卻要依靠測試來推動技術的發展，難以想像。我們(men) 需要的是一條新的發展思路。

沒有設計就根本談不上測試，相反設計才決(jue) 定了測試的體(ti) 係。例如，整車網絡的電氣特性參數，比如ECU的終端電阻、電容，這些參數都是與(yu) 特定的網絡環境有關(guan) 係的。可能因為(wei) 線束走線不同就有所不同。設計人員知道影響這些參數的原因和可能出現的問題，而這些都可以成為(wei) 建立測試方法的輸入。

董因平博士補充道，測試是比較重要，但是一定要比較的話，則更傾(qing) 向於(yu) 選擇設計更重要。其實電子行業(ye) 的發展可以成為(wei) 參考，為(wei) 什麽(me) EDA工具在電子設計中處於(yu) 如此重要的地位？而且現在國際上的趨勢是基於(yu) 係統級的設計、建模等等。重點是係統級！董因平博士還強調，如果一味隻重視測試的話，那麽(me) 就是在走國外發展的老路，是背離係統級的設計思路，根本就沒有考慮國際發展的趨勢。

應該從(cong) 哪幾個(ge) 方麵來構造協議？

CAN協議的基本要素是ID、周期和信號與(yu) 消息的映射關(guan) 係。因此構造協議的主要任務是ID分配、定義(yi) 消息周期、確定信號與(yu) 消息的映射關(guan) 係。這三個(ge) 方麵的設計都同等重要，設計要考慮的主要因素有數據傳(chuan) 輸的實時性要求（即所謂的時序）、數據的相對重要程度、與(yu) 數據相關(guan) 的應用控製算法對數據的時間要求。

董因平博士指出，協議設計實質上是非常複雜的工作，對於(yu) 國內(nei) 來說，由於(yu) 我們(men) 缺乏相應的經驗，國外又對我們(men) 進行技術？？，因此到目前為(wei) 止這還是阻礙中國技術發展的主要障礙。

國際上也存在一些現有的標準，如CANopen、SAE J1939.SAE J1939這是一個(ge) 有汽車工程師協議牽頭製定的應用與(yu) 卡車電控網絡的協議。不過它主要是應用與(yu) 卡車的電控係統，不能直接照搬到轎車控製係統中。但是隨著汽車電子的發展，汽車電子設計分工也越來越細，這部分工作也有廠商提供工具實現協議的計算機輔助設計。比如Mentor Graphics公司的VNA就是一款自動化的協議設計軟件。#p#分頁標題#e#

實現通信協議的程序代碼結構是什麽(me) 樣的？

董因平博士說：首先CAN通信功能包括物理層、數據鏈路層和應用層。物理層、數據鏈路層已經由硬件實現，目前都已經標準化，有現成的部件（CAN控製器和收發器）選擇。因此在單片機上加上CAN控製器、收發器，軟件實現相應的驅動程序就基本實現了CAN的通訊功能。但是這對於(yu) 汽車電子上的應用還是遠遠不夠的，因為(wei) 數據鏈路層有很多功能沒有定義(yi) 如具有邏輯關(guan) 係的消息之間的功能實現、網絡管理等等。

因此通信協議的程序代碼的結構應該是底層驅動+應用代碼（通信功能的應用代碼）。如果考慮目前汽車電子嵌入式軟件的技術發展，未來的結構應該是底層驅動+應用代碼+抽象層。汽車電子軟件開放式體(ti) 係標準AUTOSAR也基本是這樣的思路。目前也有很多軟件廠商提供現成的解決(jue) 方案，ECU軟件開發隻需要在該解決(jue) 方案提供的基於(yu) 數據讀寫(xie) 的接口之上實現控製算法。這樣做的好處在於(yu) 軟件設計人員可以把專(zhuan) 長用於(yu) 集中設計控製算法、保證其可靠性。這樣的產(chan) 品如Mentor Graphics的嵌入式軟件（VTP + 網絡管理 + 診斷……）就是這樣的應用例子。