引言

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

CANopen 的發(fā)展歷史

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

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

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

在 CANopen 發(fā)展過程的早期，使用 CAN 遠程幀發(fā)起數(shù)據(jù)請求的方式仍然是做常用的做法，CAN 網(wǎng)絡(luò)管理中的節(jié)點保護機制（Node Guarding）就是基于它實現(xiàn)的，不過節(jié)點保護機制在后來被心跳機制所取代。最初的 CANopen 網(wǎng)絡(luò)也使用遠程請求實現(xiàn) PDO?，F(xiàn)在，CiA 建議完全不要使用遠程幀。

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

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

表x CANopen發(fā)展大事記

CANopen 的底層

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

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

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

表x CANopen位時間對應(yīng)總線最大長度和設(shè)備間電纜接線最大長度

CANopen 根據(jù) ISO 11898-2 對物理層進行了抽象，但實際應(yīng)用領(lǐng)域的環(huán)境要求可能不完全遵守 ISO 11898-2，因此，CANopen 也可以適配其他物理層。但若適配其他物理層，設(shè)計的 CANopen 設(shè)備無法接入標準的 CANopen 網(wǎng)絡(luò)中。

CANopen 設(shè)備的內(nèi)部架構(gòu)

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

CANopen 將通信過程抽象成若干個對象，設(shè)備設(shè)計人員基于這些通信對象的實例，在具體設(shè)備中實現(xiàn)所需的網(wǎng)絡(luò)行為。使用這些通信對象，設(shè)備設(shè)計人員可以賦予設(shè)備能夠通信過程數(shù)據(jù)、指示設(shè)備內(nèi)部錯誤情況，以及控制網(wǎng)絡(luò)行為。設(shè)備設(shè)計人員也可以基于 CANopen，使設(shè)備能夠參與網(wǎng)絡(luò)中的點對點通信。由于 CANopen 定義了內(nèi)部設(shè)備結(jié)構(gòu)，系統(tǒng)設(shè)計人員可以明確地知道如何訪問 CANopen 設(shè)備以及如何調(diào)整對設(shè)備預(yù)期的行為。

一個 CANopen 設(shè)備包含三個邏輯部分：

• CANopen 協(xié)議棧處理通過 CAN 總線網(wǎng)絡(luò)的通信
• 應(yīng)用軟件提供了內(nèi)部的控制功能以及訪問硬件的接口
• CANopen 的對象字典為協(xié)議和應(yīng)用軟件提供接口。

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

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

定義 CANopen 對象字典的意義在于，任何 CANopen 設(shè)備都支持統(tǒng)一的 SDO 服務(wù)，系統(tǒng)設(shè)計人員就可以基于約定，通過網(wǎng)絡(luò)配置各設(shè)備中的對象字典，進而指定的 CANopen 設(shè)備行為。

CANopen 的協(xié)議棧

CANopen 協(xié)議棧包含了若干個協(xié)議：

• SDO 協(xié)議（服務(wù)數(shù)據(jù)對象，Service Data Object）
• PDO 協(xié)議（過程數(shù)據(jù)對象，Process Data Object）
• NMT 協(xié)議（網(wǎng)絡(luò)管理，Network Management）
• 專用功能協(xié)議（Special Function）
• 錯誤控制協(xié)議（Error Control）

每個 CANopen 協(xié)議實現(xiàn)了若干個通信對象（Communication Object）。系統(tǒng)設(shè)計人員使用 CANopen 通信對象傳遞控制信息，對某些錯誤狀態(tài)作出反應(yīng)，以及控制網(wǎng)絡(luò)行為。通過在 CANopen 對象字典中檢查是否存在描述通信行為的相關(guān)條目，以評估 CANopen 設(shè)備的能力。

SDO 協(xié)議

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

figure-canopen-sdo-protocol
圖x SDO協(xié)議通信過程

CANopen 設(shè)備可以支持不同的 SDO 協(xié)議變種：快速傳輸、常規(guī)（分段）傳輸或塊傳輸。

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

圖x SDO協(xié)議的常規(guī)傳輸

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

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

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

表x 一個SDO參數(shù)清單條目

PDO 協(xié)議

CANopen 使用過程數(shù)據(jù)對象（Process Data Object，PDO）廣播高優(yōu)先級的控制和狀態(tài)信息。PDO 由一個 CAN 幀組成，傳輸最多 8 字節(jié)的純應(yīng)用程序數(shù)據(jù)。設(shè)備設(shè)計人員必須評估設(shè)備需要接收和傳輸?shù)奶幚頂?shù)據(jù)量，以此確認在設(shè)備內(nèi)提供對應(yīng)數(shù)量的接收和發(fā)送 PDO。

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

接收 PDO 的通信參數(shù)設(shè)置在索引范圍0x1400 到0x15FF，發(fā)送 PDO 的通信參數(shù)設(shè)置在索引范圍0x1800 到0x19FF。對應(yīng)的映射項在索引范圍分別在0x1600h到17FF和0x1A00到0x1BFF。

在 PDO 的觸發(fā)事件定義了如下內(nèi)容：

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

figure-canopen-pdo-triggering-events
圖x PDO協(xié)議的觸發(fā)事件

PDO 映射定義了 PDO 中傳輸哪些應(yīng)用程序?qū)ο?。它描述映射的?yīng)用程序?qū)ο蟮捻樞蚝烷L度。應(yīng)用程序?qū)ο蟮挠成湓诿總€ PDO 的相關(guān) CANopen 對象字典條目中描述。CANopen 區(qū)分了三種類型的 PDO 映射：

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

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

1. 通過切換相關(guān) COB-ID 表項中的 31 位，將 PDO 設(shè)置為無效。
2. 通過將 0x00 寫入相關(guān)映射項的子索引 0x00h，將 PDO 映射設(shè)置為無效。
3. 調(diào)整所需的 PDO 映射。
4. 將對應(yīng)映射索引的子索引 0x00h 設(shè)置為映射對象個數(shù)。
5. 切換 PDO 為有效，操作相關(guān) COB-ID 條目中第 31 位。

MNT 協(xié)議

所有 CANopen 設(shè)備都需要支持 CANopen 網(wǎng)絡(luò)管理（NMT，Network Management）從機。NMT 的狀態(tài)機定義了 CANopen 設(shè)備的通信行為。CANopen NMT 狀態(tài)機由初始化狀態(tài)（Initialization state）、預(yù)操作狀態(tài)（Pre-operational state）、操作狀態(tài)（Operational state）和停止狀態(tài)（Stopped state）組成：

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

figure-canopen-nmt-slave
圖x NMT的狀態(tài)機

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

CANopen 網(wǎng)絡(luò)中，由激活的 NMT 主機發(fā)起 NMT 傳輸，運行 NMT 協(xié)議的從機必須接收 NMT 命令，進入 NMT 狀態(tài)機。NMT 協(xié)議采用一個數(shù)據(jù)長度為 2 字節(jié)的 CAN 幀，第一個字節(jié)包含命令說明字，第二個字節(jié)包含必須執(zhí)行命令的設(shè)備的節(jié)點 ID（如果該值等于 0，則所有節(jié)點都必須執(zhí)行命令狀態(tài)轉(zhuǎn)換）。NMT 協(xié)議幀使用 0 號 CAN 標識符，這是 CAN 總線系統(tǒng)中最高的優(yōu)先 CAN-ID。

figure-canopen-nmt-message
圖x NMT的消息幀

特殊功能協(xié)議

CANopen 提供了三個特定的協(xié)議來處理特殊的網(wǎng)絡(luò)行為：

• 同步協(xié)議（SYNC）使網(wǎng)絡(luò)行為同步。
• 時間戳協(xié)議（Time-stamp）用于調(diào)整統(tǒng)一的網(wǎng)絡(luò)時間。
• 緊急協(xié)議（Emergency）可用于通知其他網(wǎng)絡(luò)參與者設(shè)備內(nèi)部錯誤。

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

figure-canopen-sync-protocal
圖x CANopen的同步協(xié)議

時間戳協(xié)議允許 CANopen 系統(tǒng)的用戶調(diào)整到統(tǒng)一的網(wǎng)絡(luò)時間。時間戳消息是一個數(shù)據(jù)長度為 6 字節(jié)的 CAN 幀，這 6 個字節(jié)的數(shù)據(jù)提供了時間信息，從 1984 年 1 月 1 日開始計日，以午夜 0 點開始計毫秒。缺省情況下，這個 CAN 幀的 CAN 標識符為 0x100。

figure-canopen-timestamp-protocal
圖x CANopen的時間戳協(xié)議

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

figure-canopen-emcy-protocal
圖x CANopen的緊急協(xié)議

錯誤控制協(xié)議

錯誤控制協(xié)議用于監(jiān)控 CANopen 網(wǎng)絡(luò)，包括心跳協(xié)議（Heartbeat protocol）、守護協(xié)議（Guarding protocol）以及啟動協(xié)議（Boot-Up protocol）。

心跳協(xié)議用于驗證所有網(wǎng)絡(luò)參與者在 CANopen 網(wǎng)絡(luò)中仍然可用，并且它們?nèi)匀惶幱陬A(yù)期的 NMT 狀態(tài)機中。在老式的 CANopen 系統(tǒng)中，使用 CAN 遠程幀，而不是心跳協(xié)議，來實現(xiàn)守護協(xié)議。但現(xiàn)代的 CAN 不再推薦使用基于 CAN 遠程幀的服務(wù)。所有的錯誤控制協(xié)議都基于相同的 CAN 消息，其中 CAN 幀標識符為0x700 +要監(jiān)控的CANopen設(shè)備的節(jié)點ID。

心跳協(xié)議是一個定期傳輸?shù)南ⅲ尚奶⒌陌l(fā)送者通知所有心跳消息的接收者，自己仍在正常工作。此外，心跳協(xié)議還提供了心跳消息發(fā)送者的當前 NMT 狀態(tài)。心跳消息的傳輸周期可以在對象字典索引 0x1017 中配置。

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

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

CANopen 制造商 ID

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

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

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

figure-canopen-vendor-id

圖x CANopen的制造商ID

CANopen 制造商 ID 也可以用于其它通信技術(shù)機構(gòu)。表 x 中記錄了制造商 ID 的分配區(qū)間。

表x CANopen制造商的分配區(qū)間