引言

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

CANopen 的發(fā)展歷史

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

最初，CANopen 規(guī)范被命名為“工業(yè)系統(tǒng)基于 CAL 的通信配置規(guī)范”。它是在 Esprit（歐洲信息技術研究戰(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ā)控制體系結構和設備，可以將現(xiàn)有的制造單元以靈活和模塊化的方式組合起來。由 Mohammad Farsi 博士（紐卡斯爾大學）和 Stefan Reitmeier 博士（博世）領導的研究團隊決定使用由 CiA 開發(fā)的 CAN 應用層（CAL）協(xié)議作為基礎。CAL 是一種基于 OSI（Open Systems Interconnection）的純應用層的模型。然而，在某些方面，它僅僅是一種來自不同方向的設計人員提出的學術方法，它的主要貢獻來自 Tom Suters（飛利浦醫(yī)療系統(tǒng)），以及 Konrad Etschberger 教授博士和 Wolfhard lawrence 教授博士，他們都在德國大學從事應用科學工作。當然，其他 CiA 成員也提出了想法。

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

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

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

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

表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 位時間對應總線最大長度和設備間電纜接線最大長度?？偩€網(wǎng)絡中的所有 CANopen 設備必須至少支持定義的比特率之一 ，當然，CANopen 設備可以支持更多的比特率。采樣點的位置必須盡可能接近 87.5%的位時間周期中。

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

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

CANopen 設備的內(nèi)部架構

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

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

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

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

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

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

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

CANopen 的協(xié)議棧

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

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

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

SDO 協(xié)議

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

figure-canopen-sdo-protocol

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

在初始化過程中，客戶端設備指示將從服務端的對象字典中訪問哪些信息，使用哪種 SDO 類型，以及是否要讀取或?qū)懭胄畔ⅰ７斩嗽O備回應查詢請求給客戶端設備。然后，客戶端設備開始傳輸?shù)谝粋€數(shù)據(jù)段。常規(guī)傳輸允許以分段的方式傳輸任意數(shù)量的數(shù)據(jù)，每個段最多可以攜帶 7 個字節(jié)的應用程序數(shù)據(jù)，1 個字節(jié)需要用于協(xié)議信息，總共 8 個字節(jié)封裝進入 CAN 通信幀的數(shù)據(jù)負載。在正常的 SDO 傳輸中，可以交換無限數(shù)量的段，即可以交換無限數(shù)量的應用程序數(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 個段）傳輸完成后應答確認。設備制造商可以根據(jù)設備傳輸數(shù)據(jù)的體量，決定在實現(xiàn)何種 SDO 的傳輸方式。

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

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

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

PDO 協(xié)議

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

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

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

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

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

figure-canopen-pdo-triggering-events

圖x PDO協(xié)議的觸發(fā)事件PDO 映射定義了 PDO 中傳輸哪些應用程序?qū)ο蟆Ｋ枋鲇成涞膽贸绦驅(qū)ο蟮捻樞蚝烷L度。應用程序?qū)ο蟮挠成湓诿總€ PDO 的相關 CANopen 對象字典條目中描述。CANopen 區(qū)分了三種類型的 PDO 映射：

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

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

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

MNT 協(xié)議

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

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

figure-canopen-nmt-slave

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

CANopen 網(wǎng)絡中，由激活的 NMT 主機發(fā)起 NMT 傳輸，運行 NMT 協(xié)議的從機必須接收 NMT 命令，進入 NMT 狀態(tài)機。NMT 協(xié)議采用一個數(shù)據(jù)長度為 2 字節(jié)的 CAN 幀，第一個字節(jié)包含命令說明字，第二個字節(jié)包含必須執(zhí)行命令的設備的節(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)絡行為：

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

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

figure-canopen-sync-protocal

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

figure-canopen-timestamp-protocal

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

figure-canopen-emcy-protocal

圖x CANopen的緊急協(xié)議### 錯誤控制協(xié)議

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

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

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

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

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

CANopen 制造商 ID

每個 CANopen 設備需要包含一組標識參數(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ù)充當全球唯一的設備地址。一些服務（例如 LSS 和節(jié)點聲明）利用這個參數(shù)來正確識別 CANopen 設備，允許即插即用，并檢查整個系統(tǒng)的完整性。

figure-canopen-vendor-id

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

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