【CANopen】CAN总线的高级协议详解

本文是对《CANopen high-level protocol for CAN-bus.pdf》的翻译及解析。由于作者能力有限，如有错误，望纠正！
交流QQ群：429346143。
《CANopen high-level protocol for CAN-bus.pdf》的翻译及解析下载地址： https://download.csdn.net/download/xiuhua_wu/10916762

简介

从OSI七层网络模型角度来观察，现场总线网络（Fieldbus networks）通常只有第1层（物理层，Physical Layer）、第2层（数据链路层，DataLink Layer）和第7层（应用层，Application Layer）。CAN（Controller Area Network）总线也是如此，CAN总线只定义了第1层物理层和第2层数据链路层（ISO1 1898）。这两层完全由CAN硬件处理，从而大大地提高了现场总线节点固件的开发效率。

CAN总线的高级协议通过定义CAN报文的11位标识符和8字节数据的使用方式，从而保证了基于CAN标准的工业化系统的互操作性和互换性。不同制造商要求使用标准化的应用层协议和配置文件（profiles），从而实现了通信系统、设备功能和系统管理的标准化。

• 应用层（application layer）：提供一系列的服务和协议给网络上的每个设备。
• 通信配置文件（communication profile）：提供配置设备和通讯数据的方法，并定义数据如何在设备之间通信。
• 设备配置文件（device profiles）:为设备添加特定于设备的行为。

OSI（七层网络模型）	CANopen标准在OSI网络模型的映像

下面将介绍CANopen标准所在的CAN网络CAL（CAN Application layer）、CANopen本身以及定义CANopen的配置文件。

CAL（CAN Application layer）

CAL（CAN Application layer）是基于CAN网络的高层通讯协议之一，由飞利浦医疗系统发展而来。它被独立的CAN用户和制造商集团CiA采用，并进一步开发并发布了一系列的标准。CAL提供了4个应用层服务元素：

• CMS（CAN-based Message Specification，CAN报文规范）：提供了变量（Variable）、事件（Event）、域（Domain）类型的对象，设计和指定如何通过CAN接口访问设备（节点）的功能。
• NMT（Network Management，网络管理）：提供支持网络管理的服务，如：初始化、启动/停止节点、检测节点异常。这个服务是基于master-slave概念实现的。
• DBT（Distributor，经销商）：为网络上的节点提供一个动态分配的CAN标志符（官方称为：COB-ID，Communication Object Identifier）。这个服务是基于master-slave概念实现的。
• LMT（Layer Management）：提供改变层参数的功能，如：改变节点的NMT地址、改变CAN接口的bit-timing和baud-rate。

CMS定义了8个优先级组，每组有220个COB-IDs，取值范围：[1, 1760]。0和[1761, 2031]是NMT、DBT和LMT的保留标识符。在CAN网络中，COB-ID的数值越小，其在网络上的优先级越高。

NOTE：
CAL标准假定CAN2.0A（CAN Standard Message Frame）有11位的标识符，取值范围为[0, 2047]，但由于历史原因，实际取值范围限定在[0 , 2031]。在使用CAN2.0B（CAN Extended Message Frame）时，其有29位的标识符，取值范围和优先级仍符合上图的描述，图中的11位范围映射到29位COB-ID的11个最重要的位，表中的COB-ID范围将增大。

CANopen

CAL提供了所有网络管理服务和报文协议，但是它并没有定义CMS对象的内容或通讯对象的类型（it defines how, not what）。CANopen建立在CAL之上，使用了CAL服务和通讯协议的子集，提供了基于CAL服务和协议的分布式控制系统（A distributed control system）的实现，使网络节点能够从简单的功能扩展至复杂的功能，同时不影响网络节点的之间的互操作性。

CANopen的核心概念：设备对象字典（the Device Object Dictionary, OD），这是在其他现场总线系统中使用的概念（Profibus, Interbus-S）。

NOTE：
设备对象字典（Object Dictionary）的概念并不是来至CAL，它是CANopen的一个实现方式。

下面，首先先介绍设备对象字典，然后再接收CANopen通讯机制。

CANopen对象字典（CANopen Object Dictionary）

CANopen对象字典（OD）是对象的有序分组，每个对象使用16位索引寻址。为了实现对数据结构体的各个元素进行访问，还定义了一个8位的子索引（sub-index）。CANopen OD的总体布局如下图所示。

NOTE：
不要被OD中小于0x0FFF索引值的数据类型（data type）所迷惑，它们主要是为了定义而存在的。节点OD的实际相关范围为[0x1000, 0x9FFF]。

网络上的每一个节点都存在一个OD，OD包含了描述设备及其网络行为的所有参数。节点的OD主要是以EDS或纸质的数据库（database）形式存在。这不一定需要通过CAN总线查询（interrogate）节点OD中的所有参数，只要节点的行为和其在纸上的OD描述完全一致，就足够了。节点本身必须能够显示所有强制性OD条目（由CANopen指定，这些条目实际上非常少）和可选的条目（如：节点的可配置功能）。

CANopen是通过配置文件（profiles）形式定义的：

• 通讯配置文件（Communication profile）：描述了OD的一般形式、OD中通信配置文件相关的对象以及通讯参数，通常也描述CANopen的通讯对象（Communication object）。这个配置文件适用于所有的CANopen设备。
• 设备配置文件（device profile）：各种设备配置文件为特定类型的设备定义OD对象。现在大约有5种不同的设备配置文件，还有几种正在开发中。

配置文件描述了每个OD对象的功能（function）、名称（name）、索引（index）、子索引（sub-index）、数据类型（data type）、对象是否强制的（mandatory）或可选的（optional）、对象是否只读（read only）、只写（write only）或可读/写（read/write），等等。

NOTE:
设备通讯功能和对象、其设备特性相关的对象及其默认值的描述是以电子数据表（Electronic Data Sheet, EDS）的形式提供，EDS是具有严格定义语法ASCII文件。

The description of a device’s communication functionality and objects and its device-specific objects and their default values is proviced in the form of an Electronic Data Sheet (EDS), an ASCII file with a strictly defined syntax.

单个设备的对象配置描述以设备配置文件（Device Configuration File, DCF）形式提供，其结果与EDS相同。

A description of the object configuration of an individual device is called a Device Configuration File (DCF) and has the same structure as an EDS.

EDS和DCF的文件类型都在CANopen规定中定义。

配置文件定义了哪些OD对象是强制的，哪些OD对象是可选的。强制对象的数量需要保持在允许的最小实现（lean implementation）。通讯部分和设备特性相关的部分的可选功能可以根据需求添加，以扩展CANopen设备的功能。若有更多的特征被要求加入配置文件，那么配置文件需要有足够的空间来添加制造商相关的功能。

因此，描述通信参数的OD部分对所有CANopen设备都是相同的（也就是说，放置在OD中的对象是相同的，而不是对象的值）。同时，OD中不同设备特性相关的部分对于不同设备来说是不同的。

CANopen communication

上面我们已经介绍了对象字典的概念，那么现在我们来看看CANopen网络中通讯报文的内容和功能，换个词语表达：CANopen 通讯模型（CANopen Communication model）。

NOTE：
请确保OD对象（以OD索引和子索引作为特征）和通讯对象或消息（以COB-ID或CAN标识符为特征）已区分。

CANopen通讯模型定义了4种消息（messages, communication object）：

• 管理消息（Administrative meaasge）
• 服务数据对象（Service Data Object, SDO）
• 过程数据对象（Process Data Object, PDO）
• 预定义消息或特殊功能对象（Predefined messages or Special Function Objects）

上述的communication object以小节的形式进行描述。

管理消息（Administrative message）

管理消息（Administrative meaasge）包含三个内容：

• 层管理（Layer Management）
• 网络管理（network management）
• 标识符分发服务（identifier distribution services）

如：初始化（initialisation）、配置（configuration）、监督网络（supervision of the network，包含节点/生命守护（node/life guarding））等。

服务和协议是依据CAL的LMT、NMT和DBT服务元素定制的。这些服务都是遵循Master-Slave 概念：在CAN网络中，有且只有1个LMT、NMT和DBT Master，有1个或多个Slaves。

服务数据对象（Service Data Object，SDO）

每个SDO作为客户机（client）通过对象字典的索引（index）和子索引（sub-index）访问设备字典（设备作为server）中的条目，索引信息包含在CAN消息中的前几个字节中。

依据CAL的表述，SDO被实现为“多路复用域”（Multiplexed Domain）类型的CMS对象，因此允许传输任意长度的数据。在必要时数据会被分割成多个CAN消息，此时，数据占用超过4个字节。

SDO协议属于“确认服务”（confirmed service）类型：每个CAN消息生成一个应答（一个SDO需要2个CAN 标识符）。SDO请求和应答消息总是包含8个字节，因此通过SDO进行通信的开销相当大。携带协议信息的非有效字节数总是最为第一个字节的一部分显示。

过程数据对象（Process Data Object，PDO）

PDO用于传输实时数据：数据从一个生产者（producer，有且只有1个）传输至一个或多个消费者（consumers）。数据传输限制在1~8字节，如：一个PDO最大可传输64个数字I/O值或4个16位模拟输入。

PDO没有协议开销（It has no protocol overhead）。PDO的数据内容仅通过其CAN 标识符定义，并且假定发送方（sender）和接收方（receivers）都知道该内容。

每个PDO由对象字典中的两个对象描述：

• PDO通讯参数（PDO Communication Parameter）：包含PDO的COB-ID、传输类型、抑制时间和计时器周期。
• PDO映像参数（PDO Mapping Parameter）：包含映射到PDO的对象字典中的对象列表，包含它们的大小（单位：bits）。PDO的生产者（producer）和消费者（consumers）都必须知道映射关系，以便能够解析PDO的内容。

PDO消息的内容都是预定义的或者在网络启动时配置的。应用程序对象在PDO中的映射都是在设备字典中的PDO映射参数中描述的。如果设备支持可变PDO映射，那么还可以通过SDO消息对PDO消息的内容进行配置。

PDO有如下的传输模式：

• 同步（Synchronous）：通过接收同步对象（SYNC object）进行同步。
  ♢ 非周期（Acyclic）：同步非周期信息。
  █ 远程传输请求：传输是由来自另一个设备的远程传输请求“预先触发”（remote transmission request）。
  █ 指定对象（设备）特定事件：传输是由设备配置文件中指定的对象（设备）特定事件的发生“预先触发”。

transmission is ‘pre-triggered’ by the occurrence of an object- (device-)specific event specified in the device profile.

♢ 周期（cyclic）：每1/2条或最多240条同步消息后，会周期性地触发传输。

transmission is triggered periodically after every 1, 2 or up to 240 SYNC messages.

• 异步（Asynchronous）
  • 传输由来自另一个设备的远程传输请求（通过CAN远程帧）触发。
  • 传输是由设备配置文件中指定的对象（设备）特定事件的发生触发的。如：an input-change-of-value 或计时器事件。

下图介绍了CANopen中PDO传输类型的定义。对于类型1到240，数字表示两个PDO传输之间的同步对象的数量。

每个PDO可分配1个抑制时间（inhibit time），用于定义两个连续PDO传输之间的最小时间，以防止网络上的等待（starvation）。抑制时间是PDO通信参数对象的一部分。类型：unssigned 16-bit；单位：100us。

每个PDO可以分配一个事件计时器周期（event timer period）。在一个时间计时器周期内，当指定的时间已经过去，PDO传输将周期性地触发（没有出现替代触发器）。类型：unssigned 16-bit；单位：1ms。

依据CAL的说法，PDO是一个存储-事件（Stored Event）类型的CMS对象的实现。这意味着数据PDO数据传输是没有协议开销的，并且消息没有应答机制（PDO只需要1个CAN标识符）。最大能传输8字节（64比特）的数据。

预定义消息或特殊功能对象（Predefined messages or Special Function Objects）

预定义消息或特殊功能对象包含如下内容：

• 同步（Synchronization, SYNC）
• 时间戳（Time Stamp）
• 紧急（Emergency）
• 节点/生命守护（Node/Life Guarding）
• 启动（Boot-up）

同步（Synchronization，SYNC）

SYNC用于网络范围内的同步任务（尤其是与驱动程序相关的任务）。实际输入的数值准时地（quasi-simultaneously）存储在全网中，若要求传输，输出值将根据上一次的SYNC接收到的信息进行更新。

Used to synchronize tasks network-wide (particularly relevant for drive applications): actual values of inputs are stored quasi-simultaneously network-wide and subsequently transmitted (if required), output values are updated according to messages received after the previous SYNC.

SYNC基于Master-slave概念：SYNC主机发出周期新同步对象，SYNC从机在接收端（reception）执行（carry out）同步任务。

关于SYNC消息传输的同步PDO的传输是在给定的时间窗口内进行的。

Transmission of a synchronous PDO is within a given time window with respect to the transmission of the SYNC message.

SYNC在实现中是“基本变量”（Basic Variable）类型的CMS对象。

CANopen建议在高优先级组中设置一个COB-ID，确保定时同步信号。为了保证消息尽可能的短，SYNC不传输任何数据字节。

时间戳（Time Stamp）

Time Stamp为应用程序设备提供公共的时间帧参考，在实现中是“存储事件”（Stored Event）类型的CMS对象。

紧急（Emergency）

Emergency是右设备内部故障的发生而触发的，在实现中是“存储事件”（Stored Event）类型的CMS对象。

节点/生命守护（Node/Life Guarding）

Node/Life Guarding基于Master-slave概念。

Life Guarding：NMT Master 监控节点的状态称为生命守护（Life Guarding）。在接收到来至NMT Master的第一个节点守护信息后，Life Guarding在NMT Slave中启动。

检测（Detects）到设备网络接口中的错误，而不是设备本身的错误，将通过Emergency报告。

Node/Life Guarding根据NMT节点保护协议实现。一个从NMT Master到特定节点的远程传输请求，将触发一个应答，应答中包含节点的状态。

启动（Boot-up）

Boot-up基于Master-slave概念。通过发送Boot-up消息，NMT Slave 向NMT Master表明其已经从初始化状态过渡到运行前（peroperational）状态。

小结

SDO和PDO都是用于数据传输的，它们实现了两种不同的数据传输机制。

• SDO用于（大的）低优先级的设备之间的数据传输，最常应用于CANopen网络设备的配置。
• PDO用于快速的8字节的数据传输，或者，没有协议开销的数据传输（这意味着数据内容要预定义）。

CANopen设备必须支持许多的网络管理服务，并至少需要一个SDO。每个CANopen设备，无论是生产者（produces）或者消费者（consumes）要处理数据就必须有至少一个PDO。所有的其他通信对象都是可选的。

CANopen设备的CAN通信、OD和应用程序之间的关系如下图所示。

CANopen预定义的连接设置（Predefined Connection Set）

为了减小简单网络的配置工作量，CANopen定义了一个强制性的默认CAN标志符分配方案。这些标志符在初始化后立即进入预操作状态（Pre-Operational State），可以通过动态分配（dynamic distribution）的方式进行修改。设备必须仅为支持的通信对象提供相应的标识符。

分配方案（The allocation scheme）是基于将11-bit的CAN标识符分成4-bit功能码（function code）和7-bit节点标志符（Node-ID）实现的。

Node-ID是由系统集成商（system integrator）定义的，如：在设备上设置DIP开关。Node-ID的取值范围为1~127,0值是不允许使用的。

预定义连接设置定义了：

• 4个接收PDOs
• 4个发送PDOs
• 1个SDO（出现2个CAN标志符）
• 1个Emergency对象
• 1个Node-Error-Control标识符

预定义还支持未确认的NMT模块控制服务（NMT-Module-Control services）、SYNC和Time Stamp对象的广播（broadcasting）。

CAN标识符分配方案如下图所示。


标识符分配对应Master/Slave连接集，因为所有对等（peer-to-peer）的标识符都是不同，那么实际上只有Master设备才知道所有已连接的Node-IDs，Master设备可以与任意单个已连接的Slave节点（up to 127 nodes）以对等的方式通信。两个已连接的Slave是不能够通信的，因为他们并不知道对方的Node-ID。

将默认的CANopen集合（set）的标识符映射与CAL的映射进行比较，可以清楚地看到，具有特殊功能定义的CANopen对象映射到CAL的通用CMS对象时，表明CANopen通过使用更通用的CAL设施（facilities）实现一个系统。

CANopen标识符分配（identifier distribution）

CANopen的CAN标识符（或者COB-IDs）的分配有三种改变途径：

• 使用预定义的Master/Slave连接集
• 上电后修改PDO标识符
• 使用CAL DBT服务

使用预定义的Master/Slave连接集

标识符的分配是默认的，无需配置。若节点支持对PDO数据内容进行配置，那么PDO可配置是必须的。

上电后修改PDO标识符

当节点是预操作状态，使用SDO写入新值到节点OD的合适位置。

使用CAL DBT服务

连接到CANopen网络的节点或者Slave最初是通过已配置的Node-ID标识的。Node-ID可以通过设置设备上的DIP开关或者通过CAL的层管理服务（LMS）来进行配置。当网络初始化或引导时，网络Master首先与每个已连接的Slave通过“连接远程节点”（Connect Remote Node）电报（telegram）方式建立（establishes）个对话框（dialog）。

NOTE：
连接远程节点电报（Connect Remote Node telegram）是一个CAL NMT服务。

一旦建立此对话框后，用于SDOs和PDOs通讯的CAN标识符将分配到使用CAL DBT服务的节点上，这要求节点必须支持扩展启动（extended boot-up）。

CANopen 启动过程（boot-up process）

在网络初始化过程中，CANopen支持所谓的扩展启动（extended boot-up）以及所谓的最小启动过程。扩展启动时可选的，但是，所有CANopen设备或节点必须支持最小启动。这两种类型的节点可以同时存在于同一个网络中。

当标识符是通过CAL的DBT服务分配的，那么节点必须支持扩展启动。两种初始化过程都可以用设备或节点状态转换表示，如下图所示。

NMT服务用于在任意时间将选定的或所有的节点带入各种操作状态。携带NMT服务的CAN消息由CAN-Header（COB-ID=0）和2个字节组成。第1个字节包含请求服务（“NMT命令说明符”（NMT command specifier）），第2个字节包含Node-ID或者0（0表示寻址所有的节点）。

在CAN网络中，有且只有1个节点是NMT Master。NMT Master发出NMT消息并控制节点初始化过程。

若CANopen设备只支持最小启动，那么这个设备称为：最小功能设备（minimum capability devices）。最小功能设备在设备初始化结束后，自动地进入Pre-Operational状态。在这种状态下，可以通过SDO对设备参数化（device parameterization）和COB-ID分配。

通过将设备切换到Prepared状态，设备被迫地完全停止通信，如果设备支持并处于活动状态，那么设备仍可进行NMT服务和节点保护（node guarding）。

CANopen消息语法的细节（Details of CANopen message syntax）

在下面的章节中，将介绍COB-IDs是如何在CANopen预定义连接集中定义的。

NMT模块控制（NMT Module Control）

只有NMT Master能发出NMT模块控制消息，所有的Slaves必须支持NMT模块控制服务。NMT模块控制消息是没有响应的。NMT模块控制消息格式如下：

NMT节点守护（NMT Node Guarding）

NMT Master通过使用节点守护可以检测每个节点的当前状态，尤其是，当这些节点没有定期轮循数据时，这个方法特别有用。

NMT Master发送一个CAN远程帧（remote frame，no data bytes）格式如下：

NMT Slave回复如下：

或者（Alternatively），节点可以配置为周期性的心跳消息（periodical Heartbeat message）：

当带有心跳的节点启动时，它的启动信息是其第一个心跳消息。心跳用户通常是NMT Master，它应该为每个带心跳的的节点提供超时机制，并且在超时后提供适当的操作。

NOTE：
节点不允许同时支持节点保护和心跳协议。

NMT启动（NMT Boot-up）

NMT Slave发出启动消息，向NMT Master表明它从初始化状态进入了预操作状态。

PDO

举个例子，假设第2个发送PDO的映射如下所示（在CANopen中，由OD的0x1A01条目描述）：

在CANopen的I/O模块的设备配置文件（CiA DSP-401）定义中，对象0x6000的子索引0x02是节点的8bits数字输入的第二个集合；对象0x6401的子索引0x01是节点的16bits模拟输入的第一个集合。

PDO发送的CAN消息包含3个数据字节，如下所示：

通过改变对象0x1A01的内容，可以改变PDO的内容（如果节点支持可变PDO映射（variable PDO mapping））。

多路复用PDO（Multiplexor PDO，MPDO）定义，允许单个PDO通过在消息字节中包含源（source）或目标（destination）Node-ID和OD索引和子索引来发送多个变量。举个栗子，某个节点有64个16Bits模拟通道，如果没有这样的机制（mechanism），那么需要16个不同的发送PDOs来发送它的消息。

SDO

SDO用于访问设备的OD。OD访问的请求程序，称为Client；若CANopen设备的OD被访问并为请求提供服务，那么这个设备称为Server。Client的CAN消息和Server 回复的CAN消息均是由8Bytes组成（尽管并非所有字节都必须包含有意义的数据）。Client端的请求总是由Server的回复确认的。SDO传输有两种机制：

• 快速传输（Expedited transfer）：用于长度不超过4字节的数据对象。
• 分段传输（Segmented transfer）：用于长度超过4字节的数据对象。

SDO的基本结构：

SDO Command Specifier 可包含如下信息：

• 下载/上传（download / upload）
• 请求/响应（request / response）
• 分段/快速传输（segment / expedited transfer）
• CAN帧的数据字节数量（number of data bytes in this CAN-frame）
• 每个后续段的交替切换位（alternating toggle bit for each subsequent segment）

SDO共有5种请求/响应协议：

• 初始化下载域（Initiate Domain Download）
• 下载分段域（Download Domain Segment）
• 初始化上传域（Initiate Domain Upload）
• 上传分段域（Upload Domain Segment）
• 终止域传输（Abort Domain Transfer）

在最新的CANopen通信配置文件版本中，一个新的SDO传输机制是这么介绍的，块传输（Block transfer）：为了增加长度大于4字节的对象的总线吞吐量，多个段数据由1个确认消息确认（从Server下载，从Client上传）。相关协议如下：

• 初始化块下载（Initiate Block Download）
• 下载块段（Download Block Segment）
• 结束块下载（End Block Download）
• 初始化块上传（Initiate Block Upload）
• 上传块段（Upload Block Segment）
• 结束块上传（End Block Upload）

NOTE：

• Download：写到OD中；Upload：从OD中读出。
• 这些协议的SDO Command Specifier（SDO CAN消息的第一个数据字节）的语法和细节如下面小节所示。
• “-”表示don’t care，应该置为0。

初始化下载域（Initiate Domain Download）

下载分段域（Download Domain Segment）

初始化上传域（Initiate Domain Upload）

上传分段域（Upload Domain Segment）

终止域传输（Abort Domain Transfer）

SDO的Client或者Server可以通过发送带以下SDO Command Specifier的消息来终止一次SDO传输。

在终止域传输的情况下，数据字节0和1包含对象的索引，字节2包含对象子索引，数据字节4~7包含描述中止原因的32位中止码。

初始化块下载（Initiate Block Download）

下载块段（Download Block Segment）

结束块下载（End Block Download）

初始化块上传（Initiate Block Upload）

上传块段（Upload Block Segment）

结束块下载（End Block Upload）

SDO终止码（SDO Abort Codes）

SDO终止码（SDO Abort Codes）在byte4-7，大小：32bits。

紧急对象（Emergency Object）

Emergency messages 是由设备内部（致命）错误情况发生而触发的，并从相关应用程序设备传输到具有最高优先级的其他设备。它们也用于中断类型错误警报。一个Emergency messages由8字节组成，格式如下：

紧急错误码（Emergency Error Codes）如下表所示。其中，“xx”部分表示有设备配置文件定义。

错误寄存器是在设备OD（索引：0x1001）中。设备可以在这个状态字节中映射内部错误，提供当前错误的快速概览。位含义如下图所示：

Bit	Error type
0	通用的（generic）
1	电流（current ）
2	电压（voltage）
3	温度（temperature）
4	通信（communication）
5	设备配置文件特性（device profile specific）
6	Reserved（=0）
7	制造商特性（manufacturer specific ）

NOTE：
制造商特性（manufacturer specific ）错误字段可能包含关于错误的任何奇特与设备相关的附加信息。

总结

综上所述，基于CAN总线的完了通讯 CANopen标准具有如下的特点：

• 设备功能的标准化描述是设备对象字典的一种方式。
• 设备的标准化描述和它的配置都是采用ASCII格式文件：电子数据表（EDS）和设备配置文件（DCF）。
• 基于CAL CMS的数据交换与系统管理。
• 基于CAL NMT的标准化系统启动和节点保护。
• 系统范围同步操作的定义。
• 定义特定于节点的紧急消息。

通过遵循CANopen通信配置文件和相应的CANopen设备配置文件中包含的指导方针，两个独立的制造商可以生产标准化的设备，这些设备可以被合并到同一个CANopen CAN网络中。

可以区分下面3个级别的兼容性（安装兼容性的增加顺序）：

• 一致性（Conformance）：应用层兼容性。设备可以连接到CANopen网络，而不会干扰其他设备的通信。
• 互操作性（Interoperability）：通信配置文件兼容性。设备可以与网络中的其他节点交互数据。
• 可交换性（Interchangeability）：设备可以替代另一个设备配置文件兼容性。

CANopen设备至少需要（最小能力设备）：

• 一个Node_ID
• 一个OD（内容由设备功能而定）
• 一个支持强制OD条目（read-only）的SDO
• 支持以下NMT Slave服务
  • Reset_Node
  • Enter_Preoperational_State
  • Start_Remote_Node
  • Stop_Remote_Node
  • Reset_Communication
• 默认配置文件ID分配