版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
1、<p><b> 附錄二 文獻翻譯</b></p><p> CAN protocol</p><p> M .J .Schofield</p><p> The CAN protocol is an international standard defined in the ISO 11898. Beside the
2、CAN protocol itself the conformance test for the CAN protocol is defined in the ISO 16845, which guarantees the interchangeability of the CAN chips.</p><p> 1. Principles of data exchange</p><p&g
3、t; CAN is based on the “broadcast communication mechanism”, which is based on a message-oriented transmission protocol. It defines message contents rather than stations and station addresses. Every message has a message
4、 identifier, which is unique within the whole network since it defines content and also the priority of the message. This is important when several stations compete for bus access (bus arbitration). As a result of th
5、e content-oriented addressing scheme a high degree of system and</p><p><b> network.</b></p><p> 2. Real-time data transmission</p><p> In real-time processing the ur
6、gency of messages to be exchanged over the network can differ greatly: a rapidly changing dimension, e.g. engine load, has to be transmitted more frequently and therefore with less delays than other dimensions, e.g. engi
7、ne temperature. The priority, at which a message is transmitted compared to another less urgent message, is specified by the identifier of each message. The priorities are laid down during system design in the form o
8、f corresponding binary values </p><p> 3. Message frame formats</p><p> The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier
9、. The “CAN base frame” supports a length of 11 bits for the identifier, and the “CAN extended frame” supports a length of 29 bits for the identifier.</p><p> 4. CAN extended frame format</p><p>
10、; The difference between an extended frame format message and a base frame format message is the length of the identifier used. The 29-bit identifier is made up of the 11-bit identifier (“base identifier”) and an 18-bit
11、 extension (“identifier extension”). The distinction between CAN base frame format and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and transmitted
12、as recessive in case of a 29-bit frame. As the two formats have</p><p> 5. Detecting and signaling errors</p><p> Unlike other bus systems, the CAN protocol does not use acknowledgement messag
13、es but instead signals errors immediately as they occur. For error detection the CAN protocol implements three mechanisms at the message level (data link layer: OSI layer 2):</p><p> Cyclic Redundancy Check
14、 (CRC): The CRC safeguards the information in the frame by adding a frame check sequence (FCS) at the transmission end. At the receiver this FCS is re-computed and tested against the received FCS. If they do not match, t
15、here has been a CRC error. </p><p> Frame check: This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by fra
16、me checks are designated "format errors". </p><p> ACK errors: Receivers of a message acknowledge the received frames. If the transmitter does not receive an acknowledgement an ACK error is indica
17、ted. </p><p> The CAN protocol also implements two mechanisms for error detection at the bit level (physical layer: OSI layer 1):</p><p> Monitoring: The ability of the transmitter to detect e
18、rrors is based on the monitoring of bus signals. Each station that transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of global e
19、rrors and errors local to the transmitter. </p><p> Bit stuffing: The coding of the individual bits is tested at bit level. The bit representation used by CAN is "Non Return to Zero (NRZ)" coding.
20、 The synchronization edges are generated by means of bit stuffing. That means after five consecutive equal bits the transmitter inserts a stuff bit into the bit stream. This stuff bit has a complementary value, which is
21、removed by the receivers. </p><p> If one or more errors are discovered by at least one station using the above mechanisms, the current transmission is aborted by sending an "error frame". This pr
22、events other stations from accepting the message and thus ensures the consistency of data throughout the network. After transmission of an erroneous message that has been aborted, the sender automatically re-attempts tra
23、nsmission (automatic re-transmission). Nodes may again compete for bus access. However effective and efficient th</p><p><b> CAN 協(xié)議</b></p><p><b> 斯科菲爾德</b></p
24、><p> CAN協(xié)議是在ISO 11898中定義的國際標準。除了CAN協(xié)議本身,CAN協(xié)議的一致性測試在ISO 16845中定義,用于保證CAN芯片的可互換性。</p><p><b> 1.數(shù)據(jù)交換原理</b></p><p> CAN基于“廣播通訊機制”,該機制又建立在面向消息的傳送協(xié)議的基礎(chǔ)之上。它定義消息內(nèi)容而不是站和站地址。每條消
25、息都有一個消息標識符,且該消息標識符在整個網(wǎng)絡(luò)內(nèi)是獨一無二的,因為它定義了消息內(nèi)容及消息優(yōu)先權(quán)。這在多個站爭搶總線訪問(總線仲裁)的情況下很重要。 面向內(nèi)容的尋址方案帶來的結(jié)果是高度的系統(tǒng)和組態(tài)靈活性。只要新站只是接收器,可以很輕松地將站添加到現(xiàn)有的CAN網(wǎng)絡(luò),無需對目前站的任何硬件和軟件進行改動。這允許運用模塊化概念,也允許接收多重數(shù)據(jù)并實現(xiàn)分布式過程的同步。同時,數(shù)據(jù)傳輸并非基于站的特定類型的可用性。</p>
26、<p><b> 2. 實時數(shù)據(jù)傳輸</b></p><p> 在實時過程中,通過網(wǎng)絡(luò)進行交換的消息的緊急程度可以有很大差別:快速變化的單位(例如發(fā)動機載荷)需要更頻繁地進行傳輸,因此比其它單位(例如發(fā)動機溫度)的延遲更少。 </p><p> 使用每個消息的標識符來指定用于衡量消息發(fā)送的緊急程度的優(yōu)先級。優(yōu)先級在系統(tǒng)設(shè)計時就已確定下來了,它表現(xiàn)為相應(yīng)
27、的二進制值,并且無法動態(tài)地更改。二進制數(shù)最小的標識符具有最高的優(yōu)先級。 </p><p> 通過逐位觀測總線電平的每個站所含標識符的逐位仲裁機制來解決總線訪問沖突。這種情況按照顯性狀態(tài)覆蓋隱性狀態(tài)發(fā)生。所有那些帶有隱性傳輸和顯性觀測的站(節(jié)點)會失去爭搶總線訪問的機會。所有那些“爭搶失敗者”會自動成為優(yōu)先級最高的消息的接收器,且在總線再次可用之前不會重新嘗試傳輸。 </p><p>
28、按照傳輸請求對于整個系統(tǒng)的重要程度,對傳輸請求進行處理。這點在過載情況下更能證明其優(yōu)勢。由于是基于消息區(qū)分總線訪問的優(yōu)先等級,從而可以保證實時系統(tǒng)中個體的等待時間很短。</p><p><b> 3. 消息幀格式</b></p><p> CAN協(xié)議支持兩種消息幀格式,二者唯一的重大差別在于標識符的長度。“CAN基本幀/支持長度為11位的標識符,而“CAN擴展幀”
29、支持長度為29位的標識符。</p><p> 4. CAN擴展幀格式</p><p> 擴展幀格式消息與基本幀格式消息的不同在于所使用的標識符長度。29位的標識符由11位標識符(“基本標識符”)和18位擴展符(“標識符擴展”)組成。CAN基本幀格式和CAN擴展幀格式之間的區(qū)別在于IDE位的使用:在11位幀的情況下,該IDE位作為顯性位傳輸,在29位幀的情況下,該IDE位作為隱性位傳輸。
30、由于兩種格式必須共存于一根總線中,在總線訪問沖突的情況下,利用不同的格式和相同的標識符/基本標識符規(guī)定總線上的哪個信息具有較高的優(yōu)先權(quán):11位消息始終比29位消息的優(yōu)先級高。擴展格式要付出一些代價:總線等待時間較長(最小20個位時間),具有擴展格式的消息要求更多的帶寬(大約20 %),且錯誤檢測的性能較低(因為15位CRC所選用的多項式是針對112位的幀長進行優(yōu)化的)。 </p><p> 支持擴展幀格式消息
31、的CAN控制器也能夠發(fā)送和接收具有CAN基本幀格式的消息。只包括基本幀格式的CAN基礎(chǔ)框架。而CAN控制器僅支持基本幀格式,對于擴展消息只能識別和忽略。</p><p> 5. 檢測錯誤并發(fā)信號通知</p><p> 與其它總線系統(tǒng)不同,CAN協(xié)議不使用確認消息,而是在錯誤發(fā)生時發(fā)信號通知。對于錯誤檢測,CAN協(xié)議在消息級別執(zhí)行三種機制(數(shù)據(jù)鏈路層:OSI層2): </p>
32、<p> 周期性的冗余檢查(CRC):CRC通過在傳輸端添加幀檢查序列(FCS)來保護幀中的信息。在接收器處,參照接收到的FCS對該FCS進行驗算和測試。如果它們不匹配,表示已發(fā)生CRC錯誤。 </p><p> 幀檢查:該機制通過參照固定格式和幀大小來檢查位字段,以驗證所傳輸幀的結(jié)構(gòu)。通過幀檢查檢測到的錯誤被命名為“格式錯誤”。 </p><p> ACK錯誤:消息的
33、接收器確認所接收到的幀。如果發(fā)送器沒有接收到確認,表示有ACK錯誤。 </p><p> 對于位級別的錯誤檢測,CAN協(xié)議也執(zhí)行兩種機制(物理層:OSI層1): </p><p> 監(jiān)視:發(fā)送器的錯誤檢測能力基于對總線信號的監(jiān)視。傳輸消息的每個站也觀測總線電平,這樣可以檢測到發(fā)送的位與接收的位之間的差別。這能實現(xiàn)可靠地檢測全局錯誤以及發(fā)送器的本地錯誤。 </p><
34、p> 位填充:在位級別測試單個位的編碼。CAÇ采用的位表達法是“不歸零制(NRZ)”編碼。同步沿通過位填充產(chǎn)生。這表示在5個連續(xù)的相等位之后,發(fā)送器將一個填充位插入到位流中。該填充位帶有被接收器刪除的互補值。 </p><p> 如果至少一個站利用上述機制發(fā)現(xiàn)了一個或者多個錯誤,那么通過發(fā)送“錯誤幀”。 這防止其他站接受信息,從而保證了整個網(wǎng)絡(luò)的數(shù)據(jù)的一致性。一個錯誤的訊息傳遞被中止后,發(fā)送端
35、會自動re-attempts傳輸(自動傳輸)。節(jié)點可以再次爭搶總線訪問。 然而,盡管這里所描述的方法切實有效,但是在站出現(xiàn)故障的情況下,該方法會導致所有消息(包括正確的消息)被取消。如果沒有采取自我監(jiān)視的措施,總線系統(tǒng)會因此而受阻。因此,CAN協(xié)議提供一種機制將偶發(fā)性錯誤與永久性錯誤和站的本地故障區(qū)分開來??梢酝ㄟ^對站錯誤情況的統(tǒng)計評估來達到這一目的,評估的目的是識別站自身的故障或者引進一種工作模式,在該模式下CAN網(wǎng)絡(luò)的其它部
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 眾賞文庫僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 混凝土相關(guān)外文翻譯
- php相關(guān)外文翻譯
- gps相關(guān)外文翻譯
- 審計相關(guān)外文翻譯
- 紡織相關(guān)外文翻譯
- 消防相關(guān)外文翻譯
- java相關(guān)外文翻譯
- php相關(guān)外文翻譯
- plc相關(guān)外文翻譯
- 數(shù)學相關(guān)外文翻譯
- 能源相關(guān)外文翻譯
- 教學相關(guān)外文翻譯
- asp相關(guān)外文翻譯
- cad相關(guān)外文翻譯
- asp相關(guān)外文翻譯
- asp相關(guān)外文翻譯2
- 企業(yè)轉(zhuǎn)型相關(guān)外文翻譯
- 電鍍相關(guān)外文翻譯(英文)
- 電鍍相關(guān)外文翻譯(中文)
- 石油專業(yè)相關(guān)外文翻譯
評論
0/150
提交評論