[發明專利]基于消息機制的用于海量數據傳輸的CAN總線通信協議

無效

• 申請號: 200910098417.5
• 申請日: 2009-05-07
• 公開（公告）號: CN101552785A
• 公開（公告）日: 2009-10-07
• 發明（設計）人: 蔣凱;葉樹明;湯亞偉
• 申請（專利權）人: 浙江大學
• 主分類號: H04L29/06
• 分類號: H04L29/06;H04L1/16;H04L12/40
• 代理公司: 浙江杭州金通專利事務所有限公司
• 代理人: 沈孝敬

技術領域

本發明涉及計算機領域的嵌入式實時系統，更具體的說，是涉及一種應用于海量數據基于連接的CAN總線的通信協議。?

背景技術

隨著微機控制技術和工業現場總線技術的發展，基于現場總線的通信方式在工業控制中得以越來越廣泛的應用。其中CAN總線以其結構簡單，成本低廉，良好的功能特性和極高的可靠性，現場抗干擾能力強及開放性的特點而受到眾多開發者的青睞。?

CAN串行總線具有傳輸距離長、傳輸速度快的優點，并且其具有完善的錯誤檢測機制，采用“多重訪問沖突仲裁”機制的幀傳輸方式，可保證不丟失信息；每一幀中最多可以傳輸8個字節數據，可提供很高的實時性等等。性能上的優勢保證了CAN可以應用在很多的領域，在汽車工業、船舶運輸、機械控制、工廠自動化、樓宇自動化等都可以看到CAN的應用。?

CAN現場總線系統由物理層、數據鏈路層以及應用層3層構成。CAN的基本協議規范只有物理層協議和數據鏈路層協議，而利用CAN總線作為傳輸機制的系統的核心任務之一就是設計CAN總線的應用層協議。當前基于CAN總線的商業協議主要有DeviceNet和CANopen兩種協議，這兩種總線協議是通用型協議，功能齊全、結構復雜、靈活性差、傳輸效率較低，并且占用系統資源較多。而當前的嵌入式系統往往功能單一、結構簡單、資源有限，但要求傳輸速度快、可靠性與效率高，所以需要一種結構簡單的新型應用層協議。目前由浙江大學吳朝暉等人已經完成的一種應用于大量數據基于連接的CAN總線的通信協議，實現了數據大于8字節的消息發送的基于連接的應用層協議。該協議雖然實現了對大于8字節數據的打包發送，但是缺乏傳輸的響應機制，因此不能處理傳輸出錯的情況。特別是該協議只能實現最大256*7個字節數據傳輸，沒有海量數據傳輸?機制，而且不能保證數據傳輸的準確性。同時該協議基于連接，每次傳輸需要先建立連接，因此傳輸效率比較低。?

發明內容

本發明的主要目的在于克服現有技術中的不足，提供了一種適用于海量數據傳輸的基于消息機制的CAN總線通信協議。?

為了解決上述技術問題，本發明是通過以下技術方案實現的：?

基于消息機制的用于海量數據傳輸的CAN總線通信方法，其特征在于：定義設備的CAN控制器11位標識符，設備之間采用主從式連接，數據以無連接方式實現傳輸；數據傳輸采用消息機制，一條消息最多可發送65536個字節數據；當發送大于65536個字節數據時，采用打包方式，實現最大4G海量數據傳輸。?

作為一種改進，所述的多幀數據的幀序號從0到255標志，序列號從1開始分配，并且連續地循環分配下去直到最后一個單獨數據包，而單獨數據包也應該從第一個單獨數據包開始順序發送。?

作為一種改進，多幀數據除第一幀外，每幀數據必須包含一個序列號和7個字節數據。而第一幀包含數據長度信息。?

作為一種改進，海量數據傳輸時，包頭從0到65535標志，從0開始分配，并連續地分配下去直到最后一包，而單包也從第一個數據包開始順序發送。?

作為一種改進，所述的通信協議包括：主從連接管理、消息傳輸管理和海量數據傳輸管理。?

作為一種改進，所述的主從連接管理包括：主設備初始化和從設備初始化。?

作為一種改進，所述的主從連接管理實現過程如下：整個系統只能有一個主設備，最多可以有十四個從設備。主從連接管理包括主設備初始化和從設備初始化，主設備初始化先初始化從設備列表，接著初始化消息隊列并廣播注冊消息，等待從設備響應。從設備初始化從初始化消息隊列開始，接著響應主設備廣播，進入消息循環處理。所有傳輸由主設備發起。?

作為一種改進，所述的消息機制的每條消息可以是單幀數據，也可以是多幀數據。?

作為一種改進，所述的消息傳輸管理包括：消息發送、等待響應和消息接收。?

作為一種改進，所述的消息傳輸管理實現過程如下：根據消息中不同的功能代碼將消息打包成多幀進行發送，接收端同樣根據接收到的消息中不同的功能代碼將消息解包。每條消息發送完后，等待接收方的反饋消息(如果發送的為反饋消息則不再等待反饋)，確認消息是否被正確接收，即接收方在接收完整條消息后，都會發送一條反饋消息(如果接收到的消息為反饋消息則不對該消息反饋)，通知發送方內容已被正確接收。如果發送方等待1s未收到反饋消息或反饋消息錯誤，則重新發送該幀并再次等待1s。若重發到三次，則判定為故障，停止發送并提示出錯。否則繼續發送下一條消息。這樣就保證了每條消息發送的正確性。?