1 概述 現場總線是一種用于智能化現場設備和自動化系統的開放式、數字化、雙向串行、多節點的通信總線。 在實際的生產建設中，我們將會經常遇到將不同現場總線的設備集成在一起或者在某一現場總線中利用其他現場總線協議的設備的問題。這就涉及到了不同的現場總線協議的協議轉化。數據鍵路層的幀轉換是這些協議轉化中的一個很關鍵的問題。 在這里，我們以Profibus-DP和CAN這兩種當今使用廣泛的現場總線來研究現場總線的協議幀轉化。 2 CAN現場總線的傳輸層協議簡介 傳輸層是CAN協議的核心。它把接收到的報文提供給對象層，以及接收來自對象層的報文。傳輸層負責位定時及同步、報文分幀、仲裁、應答、錯誤檢測和標定、故障界定。 報文路由：報文的內容由識別符命名。識別符不指出報文的目的地，但解釋數據的含義。因此，網絡上所有的節點可以通過報文濾波確定是否應對該數據做出反應。 報文傳輸由以下4個不同的幀類型所表示和控制： ·數據幀：數據幀攜帶數據從發送器至接收器。 ·遠程幀：總線單元發出遠程幀，請求發送具有同一識別符的數據幀。 ·錯誤幀：任何單元檢測到一總線錯誤就發出錯誤幀。 ·過載幀：過載幀用以在先行的和后續的數據幀（或遠程幀）之間提供一附加的延時。 數據幀（或遠程幀）通過幀間空間與前述的各幀分開。 在這里我們以數據幀為例來分析CAN的幀結構。 2.1 數據幀 數據幀由7個不同的位場組成，如圖1所示： （1）幀起始 它標志數據幀和遠程幀的起始，由一個單獨的“顯性”位組成。 （2）仲裁域 仲裁域包括識別符（ID）和遠程發送請求位（RTR）。 識別符（ID）：識別符的長度為11位。這些位的發送順序是從ID-10到ID-0。最低位是ID-0。最高的7位（ID-10到ID-4）必須不能全是“隱性”。 RTR位：該位在數據幀里必須為“顯性”，而在遠程幀里必須為“隱性” （3）控制域 控制域由6個位組成，包括數據長度代碼和兩個將來作為擴展用的保留位。所發送的保留位必須為“顯性”。數據長度代碼指示了數據域中字節數量，長度為4個位。 （4）CRC域 CRC域包括CRC序列，其后是CRC界定符，它包含一個單獨的“隱性”位。 （5）應答域 應答域長度為2位，包含應答間隙和應答界定符。在應答域里，發送站發送兩個“隱性”位。當接收器正確地接收到有效的報文，接收器就會在應答間隙期間發送ACK信號，向發送器發送一“顯性”的位以示應答。 （6）幀結尾 每一個數據幀和遠程幀均由一標志序列界定。這個標志序列由7個“隱性”位組成。 2.2 傳輸控制 （1）幀間空隙 對于不是“錯誤被動”的站，或者此站已作為前一報文的接收器，其幀間空隙如圖4所示： 對于已作為前——報文發送器的“錯誤被動”的站，其幀間空間如圖5所示： 其中，intermission是強制性的3個隱性位。 （2）位流編碼 幀的部分，諸如幀起始、仲裁域、控制域、數據域以及CRC序列，均通過位填充的方法編碼。無論何時，發送器只要檢測到位流里有5個連續識別值的位，便自動在位流里插入——補碼位。 數據幀或遠程幀（CRC界定符、應答域和幀末尾）的剩余位域形式相同，不填充。錯誤幀和過載幀的形式也相同，但并不通過位填充的方法進行編碼。其報文里的位流根據“不返回到零”之方法來編碼。這就是說，在整個位時間里，位電平要么為“顯性”，要么為“隱性”。 CAN協議范圍只規定了“顯性”和“隱性”兩種邏輯值，而沒有明確規定表示這些邏輯電平的物理狀態。根據邏輯關系，我們可以設“顯性”邏輯值為邏輯“0”，“隱性”邏輯值為邏輯1。 3 Profibus數據鏈路層幀格式及相關的地址規定 （1）幀字符（UART字符） 幀由幀字符組成 每個幀字符由11個位組成：1個開始位（ST）；8個信息位;1個奇偶校驗位（P）;1個停止位。 （2）幀格式舉例 Profibus的幀有4種 1）無數據字段的固定長度的幀 2）有數據字段的固定長度的幀 3）有可變數據字段長度的幀 4）令牌幀 其中： SYN同步時間，所有的主動幀前都必須有。 SD1開始定界符，值l0H SD2開始定界符，值68H SD1開始定界符，值A2H SD1開始定界符，值DCH LE信息字節長度。該長度包括DA, SA,FC和DATA_UNIT。 LEr重復信息字節長度。 DA目的地址 SA源地址 FC幀控制 DATA UNIT數據字段。在固定長度的幀中為8個字符，在可變數據字段長度的幀中由LE決定，最大246個字符。 FCS幀檢查順序 ED結束定界符，值16H。 SC短應答幀的單一字符，值E5H。 （3）地址 在幀首部的地址字符結構是這樣的： 地址位組的低7位為其所指示的站地址。這樣在不擴展的情況下就有127個站地址（0～126）可以提供給主站和從站（其中127是作為全局地址來用的）。 EXT位用來指示在DATA UNIT中有無地址擴展。為了效率的緣故，Profibus-DP的數據交換功能禁止了地址擴展。 （4）服務存取點SAP ProfibuS-DP協議使用FDL的服務存取點SAP作為基本功能代碼。這個SAP有點類似于我們熟悉的TCP/IP協議中的端口： 在Profibus-DP協議中通常使用的幀格式如下，其中地址欄的最高位是1 4 幀的內容的轉化 一般說來，Profibus現場總線是主從結構的，Master和Slave之間是通過輪詢來通訊的。CAN也有主從結構的，但它的通訊方式是優先級逐位仲裁的競爭式通訊（CSMA/MBA）。 如果把這兩種現場總線連在一起的話，大多數情況下應該是把CAN段作為Profibus的Slave。 CAN的幀比較短，每個幀都有嚴格的差錯控制，在每個CAN的幀中，數據域最長是8個字節；而Profibus常用的有可變數據字段的單幀數據容量可達246字節，但它的每個字節（UART字符）都有比較好的差錯控制。在這種轉化中我們需要集中考慮地址轉化和幀的拆分問題。 4.1 地址轉化 如前所述，Profibus-DP的站地址（DA/SA）在幀中用1個字節的低7位來表示；但是CAN協議的幀中卻沒有明顯的地址位，它是利用仲裁域中的11位（CAN2. OA）或29位（CAN2.OB）表示符ID來表示幀的有關接收信息，讓接受節點自己來確定是否接收。這樣，實際上的地址信息就應當包含在ID中了。CAN協議沒有規定信息標識符（ID）的分配，可以根據不同的應用使用不同的方法。確定標識符的分配非常重要，是高層協議、應用層協議的一個主要研究項目。 在本文中，為簡單起見，我們只采用CAN2. OA格式的幀。首先我們來研究其標識符的分配方法。世界上已經有很多現場總線的高層協議是基于CAN協議的，如CANopen, Modbus，DeviceNET等。出于研究方便，現在我們就采用“HiLon協議B”，協議。 下面對“HiLon協議B”作簡單介紹。 HiLon協議B是一個通用協議。該協議基于對稱型多主網絡結構，支持廣播和點對點傳送命令數據。命令數據包可長達256字節。 協議以CAN2. OA幀結構為基礎。下圖是幀報文格式，一個CAN2. OA標準幀由11位ID、1位RTR、4位DLC、數據區（最多8個字節）組成。 PRI：保留位（可作優先級位）。通常，保留位設置為1。保留位亦可作為優先級位，這時1為低優先級0為高優先級而剩余的優先級由源地址決定，低地址優先級高。該保留功能可有效支持緊急信息傳送，如報警等。 source address：源地址，表示發送數據的節點地址，范圍只能設定為0～125。 TYPE：幀類型。見下表中的幀類型說明。 DLC：每幀字節數（1～8） destination address：目標地址，表示接收數據的節點地址，范圍只能設定為0～125。 index：索引字節。對于單幀數據，該字節表示傳輸數據的第一個字節；對于多幀數據，此字節表示索引字節，即此幀數據在數據包中的位置。 data：數據。 Profibus有127個站地址，地址范圍是0～126，127是全局地址。 兩者的差距并不大。因為只是研究用，我們不妨把HilonB協議稍許修改，地址范圍擴充到0～126，這樣做，對整個CAN幀的長度和結構并無任何影響。 于是，我們就可以對所有的Profibus設備和CAN設備統一編址。整個系統里的站地址是唯一的，在幀轉化時我們只要把相應位的地址信息直接拷貝進去就是了。 4.2 幀的拆分和合并 要把profibus的長幀裝到CAN的短幀里去，就只能把Profibus的幀里的數據拆分成適合CAN的幀傳輸的長度。 CAN幀里的數據域的長度最大只有8個字節。而且在我們給定的高層協議HiLon B中，又在數據域里拿了兩個字節作為目的地址和幀索引了，這樣就只剩下6個字節給我們傳輸數據。在最長的Profibus數據幀中，有246個數據字節。那么容納這個長幀的數據就需要246/6＝41個CAN幀。剛才我們在CAN的幀里采用一個字節作為幀的索引字節。 我們在進行幀轉化時，把Profibus的幀拆分成每部分6字節后，加上目的地址和幀索引，就可以成為CAN幀中的內容了。目的節點收齊這些幀之后再把它們連接還原，就得到了要傳送給它的信息。 反向傳輸時，我們所要做的只是順序完全相反的事情。 4.3 幀的控制信息的轉換 Profibus數據幀中的其他控制信息還有 SD2 （68H），LE（數據長度），FC（幀控制八位組），FCS（幀檢查序列），ED（16H），這些信息都是根據幀本身的數據計算出來的，用于接收方對數據的識別。所以在協議轉換器正確的接收了幀之后，這些信息也就不需要了。接下來的工作就是把收到的信息編人CAN的幀，加上CAN的控制信息，計算出CRC序列，和在一起組成CAN的幀發到CAN節點上去；反過來，當協議轉換器要把CAN的幀轉換成Profibus的幀時，也是在正確地接收CAN的幀之后，只提取其數據內容，然后按照Profibus的協議生成一幅Profibus幀。 5 差錯控制 每種現場總線通訊協議幀都有它自己的錯誤檢測方式。我們在協議轉換的兩側，要按照它們各自的方法去檢測錯誤。我們的協議轉換器如果檢測到一個錯誤，應當攔截這個錯誤。 5.1 Profibus的錯誤檢測及控制 如前所述，Profibus幀中用的是UART字符。第10位是奇偶校驗位。檢測到任何一個字符的奇偶校驗出錯，我們就知道該字符有錯誤了。 Profibus的數據幀中有一個FCS位，是通過計算DA，SA，FC 和DATA UNIT的算術和獲得的一個檢驗八位組。這個八位組可供 我們在接收到一個幀時來檢驗數據的正確性。 另外，還有些能明顯被發現的錯誤：如超時運行、有缺陷的開始定界符和結束定界符、無效的幀長度、相應次數等。協議轉化器在Profibus總線一側，就是作為一個Profibus的節點在運行。當它不正確地接收到一個主動幀時，將不處理、應答或回答。在此時隙 時間期滿后，發起方將再重試此請求。僅在接收到一個有效回答或重試（多次）不成功后，發起方才算完成了此請求。同理，如果協議轉換器發送主動幀后沒有正確的收到一個應答幀，那么它也會不停的重試，直到一定次數，才會把對方標記為不運行。 5.2 CAN的錯誤檢測及控制 5.2.1 錯誤類型 CAN協議列出了以下5種不同的錯誤類型。協議轉換器必須捕捉并處理這些錯誤。 （1）位錯誤 站單元在發送位的同時也對總線進行監視。如果所發送的位值與所監視的位值不相符合，則在此位時間里檢測到一個位錯誤（BIT ERROR）。 （2）填充錯誤 如果在使用位填充法進行編碼的信息中，出現了第6個連續相同的位電平時，將檢測到一個填充錯誤。 （3）CRC錯誤 CRC序列包括發送器的CRC計算結果。接收器計算CRC的方法與發送器相同。如果計算結果與接收到CRC序列的結果不相符，則檢測到一個CRC錯誤（CRC ERROR）。 （4）形式錯誤 當一個固定形式的位域含有1個或多個非法位，則檢測到一個“形式錯誤”（FORM ERROR）。 （5）應答錯誤 只要在ACK間隙（ACK SLOT）期間所監視的位不為“顯性”，則發送器會檢測到一個“應答錯誤”（ACKNOWLEDGMENT ERROR）。 5.2.2 故障界定狀態 CAN定義了一個故障界定狀態機制。一個節點可能處于下列三種錯誤狀態中。 （1）錯誤主動當一個錯誤主動結點檢測到上述某個錯誤時，它將發送一個錯誤主動幀，該幀由6個連續的顯性位組成。這已發送覆蓋其他任何同時發送的幀，并導致其他節點都檢測到一個填充錯誤，并依次放棄當前幀。 （2）錯誤被動當一個錯誤被動節點檢測到上述的某一個錯誤時，它將發出一個錯誤被動幀。該幀由6個連續的隱性位組成。這個幀會被同時出現的其他發送所覆蓋，如果其他站點沒有檢測到這一錯誤，不會丟棄當前幀。 （3）離線 5.2.3 錯誤處理過程 為進行故障界定，我們的協議轉換器也應當設兩種計數器：發送錯誤計數器和接受錯誤計數器。然后，我們就可以把它作為一個普通的CAN接點參與到CAN網絡的運行，故障的處理方法也是一樣的。 （1）初始化錯誤計，數器的值等于0，節點開始錯誤主動狀態，此時假設檢測到的所有錯誤都不是由該節點引起的。 （2）根據檢測到的錯誤類型使相應的計數器的值累加，有效的發送或接收又使這些計數器遞減，直至0。 （3）當這些計數器中的任何一個超出CAN定義的閾值時，該節點進人錯誤被動狀態。該節點被認為是導致錯誤的原因。 （4）當錯誤被動節點的發送及接收錯誤計數器值都減小到CAN定義的閾值以下時，節點重新進人錯誤主動狀態。 （5）當發送錯誤計數值超過CAN定義的另一個閾值時，該節點進人離線狀態。從離線狀態再進人錯誤主動狀態就需要人的干預了。 以上所述，是我們研究的現場總線協議轉換器在兩邊各自的現場總線范圍內的錯誤控制和處理方法。一定要先解決各自的錯誤，才能再進行幀的轉換。 從Pfofibus的幀轉換到CAN的幀時，就是在通過校驗確認幀的內容無誤后，才進行地址和內容的轉換，然后還要計算出該幀的CRC序列，供CAN段通訊用。反過來也是一樣。 6 結語 本文分析了Profibus和CAN的幀的特點，構思了在這兩種總線之間實現幀轉換的方法。但單純的幀轉換沒有意義，幀轉換只是現場總線的協議轉換中的一環。要實現幾種現場總線的協作，還有其他很多工作要做。 國際電工委員會IEC在1984年就開始籌備制定單一現場總線國際標準。然而，由于行業與地域發展等歷史原因，加上各公司和企業集團受自身利益的驅使，圍繞著現場總線技術的標準進行了一場大戰，最后經過多方妥協，于1999年年底通過了包含FF,Profibus等八種總線在內的IEC61158，沒有實現制定單一標準的目標。這個結局表明，在今后相當長一段時間內多種現場，總線將并存，控制網絡的系統集成與信息集成會面臨困難的復雜局面。無論是最終用戶還是制造商，普遍都在關注現場總線技術的發展新動向，都在尋求高性能低成本的解決方案。