引言

CAN 總線外設驅動程序能夠提供基本的操作硬件電路系統的服務，但在具體的應用系統中，更多是基于協議棧開發上層應用，而不是針對某個具體的芯片平臺編寫定制的應用程序。目前 CANopen 是工業自動化領域最常用的 CAN 協議棧標準之一，它包含了高層的交互協議和配置文件規范，用于構建高度靈活配置能力的標準化嵌入式網絡。CANopen 使開發人員從處理 CAN 硬件特定細節（如位計時和接收過濾）中解脫出來，它使用標準化的通信對象（Communication Objects, COB），處理關注時效的進程、配置過程以及管理網絡。

CANopen 的發展歷史

1994 年 11 月，CiA 發布了 CANopen 規范的第一個版本，CiA 301。這是最成功的 Esprit 研究項目之一。CANopen 成功的故事是獨一無二的，因為它不是由一家大型供應商推動的，而是由許多中小型公司以及機器制造商共同推動的。

最初，CANopen 規范被命名為“工業系統基于 CAL 的通信配置規范”。它是在 Esprit（歐洲信息技術研究戰略計劃，European Strategic Program on Research in Information Technology）的支持下開發的。編號為 7302 項目的標題是 ASPIC，是“使用接入總線概念的生產單元的自動化和控制系統（Automation and Control Systems for Production Units using an Installation Bus Concept）”的縮寫，目標是開發控制體系結構和設備，可以將現有的制造單元以靈活和模塊化的方式組合起來。由 Mohammad Farsi 博士（紐卡斯爾大學）和 Stefan Reitmeier 博士（博世）領導的研究團隊決定使用由 CiA 開發的 CAN 應用層（CAL）協議作為基礎。CAL 是一種基于 OSI（Open Systems Interconnection）的純應用層的模型。然而，在某些方面，它僅僅是一種來自不同方向的設計人員提出的學術方法，它的主要貢獻來自 Tom Suters（飛利浦醫療系統），以及 Konrad Etschberger 教授博士和 Wolfhard lawrence 教授博士，他們都在德國大學從事應用科學工作。當然，其他 CiA 成員也提出了想法。

ASPIC 項目的目標是開發一個易于實現的應用層，專門用于控制嵌入式設備。在 Bosch 的領導下，幾家公司（Moog、ADL Automation 和 J.L. Automation）和研究所（紐卡斯爾大學和 Reutlingen 應用科學大學）定義了今天被稱為 CANopen 的第一個版本，主要貢獻者是 Mohamad Farsi 博士和 Gerhard Gruhler 教授。第一個版本已經定義了 PDO（流程數據對象，Process Data Object）和 SDO（服務數據對象，Service Data Object），引入了 PDO 的同步傳輸以及網絡管理(NMT)和緊急消息。

在 CANopen 發展過程的早期，使用 CAN 遠程幀發起數據請求的方式仍然是做常用的做法，CAN 網絡管理中的節點保護機制（Node Guarding）就是基于它實現的，不過節點保護機制在后來被心跳機制所取代。最初的 CANopen 網絡也使用遠程請求實現 PDO。現在，CiA 建議完全不要使用遠程幀。

CANopen 可以看作是中小供應商的應用層，它是一個不是由一個市場主導的、獨立的工業通信系統。它也可以被看作是系統設計人員的解決方案，因為一些設備制造商已經選擇了獨立于供應商的這種方法完成設計，這些機器制造商包括了 Heidelberger 和 Siemens Healthcare。1995 年，CiA 在其漢諾威博覽會上展示了最早的 CANopen 演示方案，整合了 Moog、Selectron 和其他供應商的產品。

作為 CiA 301 發布的 CANopen 規范，是最成功的 Esprit 研究項目之一。該規范被移交給 CiA 進行進一步的開發和維護。一開始，一些公司在現實應用中實現了高層協議。后來，經過進行一些審查和更新，CANopen 逐漸成為一個穩定的規范。3.0 版本是第一個用于產品和系統的版本。這個版本從 1996 年到 1999 年有效，一些應用程序至今仍在使用這個版本。

表x CANopen發展大事記

CANopen 的底層

CANopen 的數據鏈路層基于 ISO 11898-1 的 CAN 總線。CiA 301 中指定了 CANopen 位計時規范，允許數據速率從 10k bsp 調整到 1M bps。雖然所有指定的 CAN-ID 尋址模式都基于 11 位的 CAN-ID，但 CANopen 也支持 29 位的 CAN-ID。CANopen 根據 ISO 11898-2 對物理層進行了抽象，但同時，CANopen 也并不排除其他可能使用的物理層。

CANopen 的數據鏈路層基于 ISO 11898-1 的 CAN 總線。盡管大多數尋址模式都基于基本幀格式，但 CANopen 也支持擴展幀格式。直到 CANopen 版本 CiA 301 V4.2, CANopen 只支持經典的 CAN。從 CiA 301 V5.0 版本開始，CANopen 是基于 CAN FD 的。

表 x 羅列了 CANopen 位時間對應總線最大長度和設備間電纜接線最大長度。總線網絡中的所有 CANopen 設備必須至少支持定義的比特率之一 ，當然，CANopen 設備可以支持更多的比特率。采樣點的位置必須盡可能接近 87.5%的位時間周期中。

表x CANopen位時間對應總線最大長度和設備間電纜接線最大長度

CANopen 根據 ISO 11898-2 對物理層進行了抽象，但實際應用領域的環境要求可能不完全遵守 ISO 11898-2，因此，CANopen 也可以適配其他物理層。但若適配其他物理層，設計的 CANopen 設備無法接入標準的 CANopen 網絡中。

CANopen 設備的內部架構

標準化的 CANopen 設備和應用程序配置文件簡化了集成 CANopen 系統的任務，能夠方便地適配到現存的設備、工具和協議棧。對于系統設計人員來說，復用應用軟件是非常重要的，這不僅要求兼容通信數據，而且要求設備能夠相互操作甚至相互替換。CANopen 設備、接口和應用程序配置文件使設備制造商能夠為其產品提供標準化接口，從而在 CANopen 網絡中實現具有“即插即用”功能的 CANopen 設備。不僅如此，CANopen 還允許制造商繼續擴展跟多專用功能。

CANopen 將通信過程抽象成若干個對象，設備設計人員基于這些通信對象的實例，在具體設備中實現所需的網絡行為。使用這些通信對象，設備設計人員可以賦予設備能夠通信過程數據、指示設備內部錯誤情況，以及控制網絡行為。設備設計人員也可以基于 CANopen，使設備能夠參與網絡中的點對點通信。由于 CANopen 定義了內部設備結構，系統設計人員可以明確地知道如何訪問 CANopen 設備以及如何調整對設備預期的行為。

一個 CANopen 設備包含三個邏輯部分：

• CANopen 協議棧處理通過 CAN 總線網絡的通信
• 應用軟件提供了內部的控制功能以及訪問硬件的接口
• CANopen 的對象字典為協議和應用軟件提供接口。

CANopen 的對象字典（Object Dictionary）對于 CANopen 設備配置和診斷是至關重要的，其中包含所有使用的數據類型的引用（索引），并存儲所有通信和應用程序的配置參數。設備內部的引用使用一個以 4 位 16 進制值表示 16 位數值的索引。其中，0x1000 到 0x1FFF 的索引范圍，定義了 CANopen 設備中所有 CANopen 通信行為的參數。如表 x 所示。

表x CANopen對象字典的索引空間

定義 CANopen 對象字典的意義在于，任何 CANopen 設備都支持統一的 SDO 服務，系統設計人員就可以基于約定，通過網絡配置各設備中的對象字典，進而指定的 CANopen 設備行為。

CANopen 的協議棧

CANopen 協議棧包含了若干個協議：

• SDO 協議（服務數據對象，Service Data Object）
• PDO 協議（過程數據對象，Process Data Object）
• NMT 協議（網絡管理，Network Management）
• 專用功能協議（Special Function）
• 錯誤控制協議（Error Control）

每個 CANopen 協議實現了若干個通信對象（Communication Object）。系統設計人員使用 CANopen 通信對象傳遞控制信息，對某些錯誤狀態作出反應，以及控制網絡行為。通過在 CANopen 對象字典中檢查是否存在描述通信行為的相關條目，以評估 CANopen 設備的能力。

SDO 協議

SDO（服務數據對象，Service Data Object）允許訪問 CANopen 對象字典的所有條目。一個 SDO 由兩個具有不同標識符的 CAN 數據幀組成，可以在 CAN 總線網絡上建立兩個 CANopen 設備之間的點對點的“客戶端-服務端”通信。被訪問對象字典的所有者充當 SDO 的服務端，訪問另一個設備的對象字典的設備是 SDO 客戶機。如圖 x 所示。

figure-canopen-sdo-protocol

圖x SDO協議通信過程CANopen 設備可以支持不同的 SDO 協議變種：快速傳輸、常規（分段）傳輸或塊傳輸。

在初始化過程中，客戶端設備指示將從服務端的對象字典中訪問哪些信息，使用哪種 SDO 類型，以及是否要讀取或寫入信息。服務端設備回應查詢請求給客戶端設備。然后，客戶端設備開始傳輸第一個數據段。常規傳輸允許以分段的方式傳輸任意數量的數據，每個段最多可以攜帶 7 個字節的應用程序數據，1 個字節需要用于協議信息，總共 8 個字節封裝進入 CAN 通信幀的數據負載。在正常的 SDO 傳輸中，可以交換無限數量的段，即可以交換無限數量的應用程序數據，如圖 x 所示。

圖x SDO協議的常規傳輸除了基本的常規傳輸，SDO 還可以使用快速傳輸和塊傳輸分別提升不同數據負載情況下的傳輸效率。使用快速 SDO 傳輸可以加速小數據負載（小于或等于 4 字節）的 SDO 傳輸，此時，在 SDO 連接啟動期間可以直接傳輸數據。使用 SDO 塊傳輸可以加速大數據負載的傳輸，此時，接收端不會確認單個數據段（像常規傳輸過程一樣)，而是只是在一個數據塊（最多 127 個段）傳輸完成后應答確認。設備制造商可以根據設備傳輸數據的體量，決定在實現何種 SDO 的傳輸方式。

CANopen 設備可以支持 SDO 客戶端或服務端的多個通道。如果設備支持 SDO 客戶端通道，則該設備能夠訪問其他連入網絡設備的對象字典。如果設備支持服務端通道，則設備可為其他連入網絡的設備提供訪問自身的對象字典條目的機會。設備制造商在設計設備時，必須確認他們的設備是否需要訪問其他設備，或者被其他設備訪問，然后，再確認需要實現多少個 SDO 客戶端和服務端的通道。第一個 SDO 服務端通道已經預先由規范嚴格定義，并且必須在所有 CANopen 設備上實現。

SDO 參數清單位于對象字典索引范圍0x1200 ~ 0x12FF，其中，SDO 服務端通道的參數位于從0x1200到0x127F，SDO 客戶端通道的參數位于0x1280F到0x12FF的范圍內提供。SDO 參數清單包含兩個通信對象 ID（communication object identifier，COB-ID）和相關通信節點的節點 ID（Node-ID）。COB-ID 條目涵蓋了用于在服務端到客戶端方向上和客戶端到服務端方向上傳輸信息的 CAN 幀的 ID。如表 x 所示。

表x 一個SDO參數清單條目

PDO 協議

CANopen 使用過程數據對象（Process Data Object，PDO）廣播高優先級的控制和狀態信息。PDO 由一個 CAN 幀組成，傳輸最多 8 字節的純應用程序數據。設備設計人員必須評估設備需要接收和傳輸的處理數據量，以此確認在設備內提供對應數量的接收和發送 PDO。

當設備支持 PDO 的傳輸/接收時，需要在該設備的對象字典中提供該 PDO 相應的參數清單。一個 PDO 需要一組通信參數和一組映射參數。其中，通信參數指示此 PDO 使用的 CAN 通信幀的 ID，以及相關 PDO 傳輸的觸發事件。映射參數表示應該傳輸本地對象字典中的哪些信息，以及將接收到的信息存儲在何處。

接收 PDO 的通信參數設置在索引范圍0x1400 到0x15FF，發送 PDO 的通信參數設置在索引范圍0x1800 到0x19FF。對應的映射項在索引范圍分別在0x1600h到17FF和0x1A00到0x1BFF。

在 PDO 的觸發事件定義了如下內容：

• 事件或定時器驅動：設備內部事件觸發 PDO 傳輸（例如，當溫度值超過某個限制或者某個定時器超時等等）。
• 遠程請求：由于 PDO 由單個 CAN 數據幀組成，因此可以通過遠程傳輸請求（RTR）請求它們。
• 同步傳輸（循環）：PDO 的傳輸可以耦合到 SYNC 消息的接收。
• 同步傳輸（無循環）：這些 PDO 可由具體設備的事件觸發，但與下一個同步消息的接收一起傳輸。

figure-canopen-pdo-triggering-events

圖x PDO協議的觸發事件PDO 映射定義了 PDO 中傳輸哪些應用程序對象。它描述映射的應用程序對象的順序和長度。應用程序對象的映射在每個 PDO 的相關 CANopen 對象字典條目中描述。CANopen 區分了三種類型的 PDO 映射：

• 靜態 PDO 映射：靜態 PDO 映射描述了 PDO 的內容由設備制造商預定義，不能通過 CANopen 接口更改。
• 可變 PDO 映射：可變 PDO 映射描述了 PDO 的映射項可以在 NMT 預操作狀態下更改。
• 動態 PDO 映射：動態 PDO 映射描述了 PDO 映射項在 NMT 運行狀態下也可以改變。

除去已經預定義的映射，設備設計人員可以選擇更改部分 PDO 的映射。在 CANopen 中，這種靈活可調的 PDO 映射能力稱為可變 PDO 映射或動態 PDO 映射。在支持可變映射或動態映射的情況下，PDO 的映射項只能通過使用定義的映射過程來更改：

1. 通過切換相關 COB-ID 表項中的 31 位，將 PDO 設置為無效。
2. 通過將 0x00 寫入相關映射項的子索引 0x00h，將 PDO 映射設置為無效。
3. 調整所需的 PDO 映射。
4. 將對應映射索引的子索引 0x00h 設置為映射對象個數。
5. 切換 PDO 為有效，操作相關 COB-ID 條目中第 31 位。

MNT 協議

所有 CANopen 設備都需要支持 CANopen 網絡管理（NMT，Network Management）從機。NMT 的狀態機定義了 CANopen 設備的通信行為。CANopen NMT 狀態機由初始化狀態（Initialization state）、預操作狀態（Pre-operational state）、操作狀態（Operational state）和停止狀態（Stopped state）組成：

• 設備上電或復位后，進入“初始化”狀態。設備初始化完成后，會自動過渡到預操作狀態，并發送啟動消息通知，表明它已經準備好工作了。
• 處于預操作狀態的設備可以開始傳輸同步消息、時間戳消息或心跳消息，前提是這些服務得到了支持并且配置正確。此狀態下，設備可以通過 SDO 進行通信，但不能使用 PDO 通信（PDO 通信只能在操作狀態下進行）。
• 在操作狀態下，設備可以使用所有支持的通信對象。
• 設備在切換到停止狀態時，僅對接收到的 NMT 命令作出反應。此外，在停止狀態下，設備通過支持錯誤控制協議來指示 NMT 的當前狀態。

figure-canopen-nmt-slave

圖x NMT的狀態機初始化狀態包括初始化、重置應用程序和重置通信三種子狀態。在初始化過程中，設備啟動并初始化其內部參數。引入了兩個子狀態，重置應用程序和重置通信，來啟用部分重置命令。在重置應用程序期間，對象字典中從 0x2000 到 0x9FFF 的所有參數都被設置為上電默認值。在上電后，自動進入 NMT 子狀態重置通信，通信配置文件的參數（索引范圍 0x1xxx）被設置為它們的上電默認值，之后，離開初始化狀態。

CANopen 網絡中，由激活的 NMT 主機發起 NMT 傳輸，運行 NMT 協議的從機必須接收 NMT 命令，進入 NMT 狀態機。NMT 協議采用一個數據長度為 2 字節的 CAN 幀，第一個字節包含命令說明字，第二個字節包含必須執行命令的設備的節點 ID（如果該值等于 0，則所有節點都必須執行命令狀態轉換）。NMT 協議幀使用 0 號 CAN 標識符，這是 CAN 總線系統中最高的優先 CAN-ID。

figure-canopen-nmt-message

圖x NMT的消息幀### 特殊功能協議

CANopen 提供了三個特定的協議來處理特殊的網絡行為：

• 同步協議（SYNC）使網絡行為同步。
• 時間戳協議（Time-stamp）用于調整統一的網絡時間。
• 緊急協議（Emergency）可用于通知其他網絡參與者設備內部錯誤。

同步協議由同步消息生產者周期性地輸出，兩個連續的同步消息之間的時間周期為通信周期。同步消息使用 ID 為 0x80 的單 CAN 幀。默認情況下，同步消息不攜帶任何數據（DLC = 0，CAN 幀的數據負載長度為 0）。支持 CiA 301 v4.1 或更高版本的設備可以選擇附加一個 SYNC 消息，提供一個 1 字節的同步計數器值。使用同步協議，可以更方便地協調多個設備的同步行為。

figure-canopen-sync-protocal

圖x CANopen的同步協議時間戳協議允許 CANopen 系統的用戶調整到統一的網絡時間。時間戳消息是一個數據長度為 6 字節的 CAN 幀，這 6 個字節的數據提供了時間信息，從 1984 年 1 月 1 日開始計日，以午夜 0 點開始計毫秒。缺省情況下，這個 CAN 幀的 CAN 標識符為 0x100。

figure-canopen-timestamp-protocal

圖x CANopen的時間戳協議緊急消息可由設備內部的錯誤事件觸發。由緊急事件的發生者傳輸的緊急消息是一個 CAN 幀，該幀最多包含 8 字節的數據，數據內容定義為 1 字節錯誤寄存器（本地對象字典的索引 0x1001）、16 位緊急錯誤代碼和最多 5 字節的特定于制造商的錯誤信息。默認情況下，可以產生緊急消息的設備將 CAN 標識符0x80h + (節點ID)分配給緊急消息。對每個錯誤事件只傳輸一次緊急消息，只要設備上沒有出現新的錯誤，就不會再發送任何緊急消息。零個或多個緊急消息的接受者可能會收到這些消息，并可能啟動合適的、特定于應用程序的對策措施。

figure-canopen-emcy-protocal

圖x CANopen的緊急協議### 錯誤控制協議

錯誤控制協議用于監控 CANopen 網絡，包括心跳協議（Heartbeat protocol）、守護協議（Guarding protocol）以及啟動協議（Boot-Up protocol）。

心跳協議用于驗證所有網絡參與者在 CANopen 網絡中仍然可用，并且它們仍然處于預期的 NMT 狀態機中。在老式的 CANopen 系統中，使用 CAN 遠程幀，而不是心跳協議，來實現守護協議。但現代的 CAN 不再推薦使用基于 CAN 遠程幀的服務。所有的錯誤控制協議都基于相同的 CAN 消息，其中 CAN 幀標識符為0x700 +要監控的CANopen設備的節點ID。

心跳協議是一個定期傳輸的消息，由心跳消息的發送者通知所有心跳消息的接收者，自己仍在正常工作。此外，心跳協議還提供了心跳消息發送者的當前 NMT 狀態。心跳消息的傳輸周期可以在對象字典索引 0x1017 中配置。

保護協議是一種過時的方法，用于檢查受保護的 CANopen 設備是否仍在正確的網絡狀態下工作，這是一個基于 CAN 遠程幀的服務（CiA 不建議使用 CAN 遠程幀，因為遠程幀帶來的麻煩遠比它能夠解決的問題多），后來被心跳協議所取代。例如，在老式的應用程序中，主控制器通過 CAN 遠程幀請求被監控 CANopen 設備的錯誤控制信息，每個被管控的設備回應一個 CAN 數據幀，表示當前 NMT 狀態。

啟動協議表示一種特殊類型的錯誤控制協議。在 NMT 初始化狀態之前，它作為 NMT 預操作狀態前的最后一個傳輸動作，接收到此消息表明新設備已經注冊到 CANopen 網絡。如果在運行期間意外接收到這樣的協議，要么表明網絡設置發生了變化（例如，添加了新的 CANopen 設備），要么被認為是錯誤條件的標志（例如，某些 CANopen 設備的錯誤上電)。該協議使用與任何其他錯誤控制協議（例如心跳協議）相同的 CAN 幀標識符，1 字節的數據字段使用一個固定的值 0。

CANopen 制造商 ID

每個 CANopen 設備需要包含一組標識參數，其中就包含了 CANopen 制造商 ID（CANopen Vendor-ID）。CiA 定義這個制造商 ID 為一個 32 位的數值。對于 CiA 成員，這個制造商 ID 是可以免費申請的。

CANopen v4.0 和 EN 50325-4 要求，CANopen 的制造商 ID 用于標識 CANopen 產品的制造商（商業公司或大型組織的部門）。所有的制造商 ID 均由 CiA 分配。

CANopen 制造商 ID 是 CANopen 設備的標識參數的一部分，標識參數充當全球唯一的設備地址。一些服務（例如 LSS 和節點聲明）利用這個參數來正確識別 CANopen 設備，允許即插即用，并檢查整個系統的完整性。

figure-canopen-vendor-id

圖x CANopen的制造商IDCANopen 制造商 ID 也可以用于其它通信技術機構。表 x 中記錄了制造商 ID 的分配區間。

表x CANopen制造商的分配區間