應該從哪幾個方面來構造協議？

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

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

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

　　實現通信協議的程序代碼結構是什么樣的？

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

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