CAN總線開發(fā)-CANopen協(xié)議概述

引言

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

CANopen 的發(fā)展歷史

1994 年 11 月，CiA 發(fā)布了 CANopen 規(guī)范的第一個(gè)版本，CiA 301。這是最成功的 Esprit 研究項(xiàng)目之一。CANopen 成功的故事是獨(dú)一無二的，因?yàn)樗皇怯梢患掖笮凸?yīng)商推動(dòng)的，而是由許多中小型公司以及機(jī)器制造商共同推動(dòng)的。

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

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

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

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

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

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

CANopen 的底層

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

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

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

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

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

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

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

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

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

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)部的引用使用一個(gè)以 4 位 16 進(jìn)制值表示 16 位數(shù)值的索引。其中，0x1000 到 0x1FFF 的索引范圍，定義了 CANopen 設(shè)備中所有 CANopen 通信行為的參數(shù)。如表 x 所示。

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

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

CANopen 的協(xié)議棧

CANopen 協(xié)議棧包含了若干個(gè)協(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）
錯(cuò)誤控制協(xié)議（Error Control）

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

SDO 協(xié)議

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

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

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

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

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

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

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

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

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

PDO 協(xié)議

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

當(dāng)設(shè)備支持 PDO 的傳輸/接收時(shí)，需要在該設(shè)備的對象字典中提供該 PDO 相應(yīng)的參數(shù)清單。一個(gè) 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)的映射項(xiàng)在索引范圍分別在0x1600h到17FF和0x1A00到0x1BFF。

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

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

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

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

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

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

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

MNT 協(xié)議

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

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

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

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

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

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

特殊功能協(xié)議

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

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

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

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

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

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

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

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

錯(cuò)誤控制協(xié)議

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

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

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

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

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

CANopen 制造商 ID

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

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

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