1.物理层非常稳定；2. 数据链路层可靠，因为相比其他所有总线，只有CAN可以做到达到汉明间距(Hamming Distanz)为6，能够检测报文里多达5个随机引入的位错误及15位突发性错误。3. 灵活，兼容性高；4. 可互操作性高；5. 价格低 （对于设备生产商来说）；6. CAN产品尺寸小，节省空间；7.支持冗余备用

CANopen 设备都需要具备对象字典，用来设定设备组态及进行非即时的通讯。对象字典的entry 定义如下：

索引 (Index)：对象 16 位元的位址。 对象名称 (Object name)：一个代表对象的 symbolic type，可以是阵列、纪录或只是一个变量。 名称 (Name)：描述此 entry 的字串。 形态 (Type)：变量的资料形态。 属性 (Attribute)：提供此 entry 是否可读/可写的资料，有下列四种：可读/写、只读、唯写、只读常数。 必须 (Mandatory)/可选 (Optional)字段定义属于特定设备规范下的设备，是否必须实现某些对象。 在 CANopen 标准中定义了对象字典中的基本资料型态，包括逻辑值、整数及浮点数。也定义了复合对象：如阵列、记录及字串。复合对象用一个 8 位元的数值作为其子索引(subindex)。记录或阵列中子索引 0 的位置记录此数据结构的元素个数，资料型态为 UNSIGNED8。

例如在 CiA301 标准中，设备通讯的参数放在索引范围 0x1000 - 0x1FFF (通讯行规区)。此区域的前几项如下：

若配合适当的工具，可以用编辑电子资料表（electronic data sheet, EDS）档案的方式规划一个设备，并且将变量的数值上传到设备中。EDS 档案的格式通常会是INI档。

CANopen 的物理层 CANbus 每次传送的数据量不大，其中包括 11 位元的 ID、远端传输请求（RTR）位元及大小不超过8字节的资料。CANopen 将 CANbus 11 位元的 ID 分为 4 位元的功能码及 7 位元的 CANopen 节点 ID。7 位元的 ID 共有 128 种不同的组合，其中 ID 0 不使用，因此一个 CANopen 网络上最多允许 127 台设备。CANbus 在 CAN 2.0 B 规格中允许 29 位元的 ID，因此若配合 CAN 2.0 B 使用，CANopen 网络上可以超过127 台设备，不过在实际运用中，大多数的 CANopen 网络上设备数量均低于此数值。

CANopen 将 CANbus 的 11 位元 ID 称为通讯对象 ID (COB-ID)。当传输数据发生冲突时，CANbus 的仲裁机制会使 COB-ID 最小的讯息继续传送，不用等待或重传。COB-ID 的前 4 个位元是 CANopen 的功能码，因此数值小的功能码表示对应的功能重要，允许的延迟时间较短。

以下是一个标准的 CANopen 页框：

在 CANopen 标准中，部份 COB-ID 被保留作网络管理及 SDO 通讯用。而在设备初始化后，有些功能码和 COB-ID 会对映到标准的功能，不过后续仍可以规划为其他用途。

CANopen 设备间的通讯可分为以下三种通讯模型。

在 master/slave 模型中，一个 CANopen 设备为 master，负责传送或接收其他设备（称为 slave）的数据。NMT 协定就使用了 master/slave 模型。 客户机/服务器（client/server）模型定义在 SDO 协定中，SDO client 将对象字典的索引及子索引传送给 SDO server，因此会产生一个或数个需求数据（对象字典中，索引及子索引对应的内容）的 SDO 封包。 生产者/消费者（producer/consumer）模型用在 Heartbeat and Node Guarding 协定。由一个生产者送出数据给消费者，同一个生产者的数据可能给一个以上的消费者。又可分为二种： push-model：生产者会自动送出数据给消费者。 pull-model：消费者需送出请求讯息，生产者才会送出数据。

CANopen参考模型：

CANopen设备模型：

NMT 协议NMT（网络管理, Network management）协议会定义（设备内部）状态机的状态变更命令（如启动设备或停止设备）、侦测远端设备 bootup及故障情形。

NMT master 使用的模组控制协定可变更设备的状态。其 COB-ID 为 0，其功能码及节点 ID 均为 0，因此网络上的所有节点均会处理这个信息。在此信息的数据部份会有此信息实际针对节点的ID，此 ID 也可为 0，表示所有节点都要变更为指定的状态。

心跳协议（Heartbeat protocol）是用来监控网络中的节点及确认其正常工作。心跳信息的生产者（一般是 slave 设备）周期性的送出功能码 1110、ID 为本身节点 ID 的讯息，信息的数据部分有一个表示节点状态的位。而心跳信息的消费者负责接收上述数据，若在指定时间（于设备的对象字典中定义）内，消费者均未收到信息，可采取相应动作（例如显示错误或重置该设备）。

其格式为：

COBID + DATA(status of node) CANopen 设备需要在 bootup 时自动从 Initializing 状态切换至 Pre-operational 状态，设备会在切换完成后送出一个心跳信息，这就是心跳协议。

有一种 pull model 的 NMT 协议，称作节点监控（Node guarding）协议，也可以作从机的监控。

SDO 协议

服务数据对象(SDO)可用来存取远端节点的对象字典，读取或设定其中的数据。提供对象字典的节点称为SDO server，存取对象字典的节点称为SDO client。SDO 通讯一定由SDO client 开始，并提供初始化相关的参数。

在CANopen的术语中，上传是指由 SDO server 中读取数据，而下载是指设定 SDO server 的数据。

由于对象字典中的数据长度可能超过8个字节，无法只用一个CAN数据包传输，SDO也支援长数据包的分割（segmentation）和合并（desegmentation）。这样的对象有二种：SDO下载/上传（SDO download/upload）及SDO区块下载/上传（SDO Block download/upload）。CANopen协议较新版本支援SDO区块传输，可以允许传输大量的数据，且传输的overhead可以较低。

负责处理SDO数据传输的COB ID可在对象字典中设置。在对象字典的索引0x1200至0x127F可设定SDO server的COB ID，最多可设定到127个。而SDO client可以在对象字典的索引0x1280至0x12FF中设定。不过预定义连结（pre-defined connection set）定义在开机后（Pre-operational状态）可用来设定设备组态的SDO。接收用的COB ID为0x600 +节点ID，而传送用的COB为0x580 +节点ID。

PDO 协定

过程数据对象 (PDO) 协议可用来在许多节点之间交换即时的数据。可透过一个 PDO ，传送最多 8 字节（64位）数据给一设备，或由一设备接收最多 8 字节（64位元）的数据。一个 PDO 可以由对象字典中几个不同索引的数据组成，规划方式则是透过对象字典中对应 PDO mapping 及 PDO 参数的索引。

PDO 分为两种：传送用的 TPDO 及接收用的 RPDO。一个节点的 TPDO 是将数据由此节点传输到其他节点，而 RPDO 则是接收由其他节点传输的数据。一个节点分别有 4 个 TPDO 及 4 个 RPDO 。

PDO 可以用同步或异步的方式传送：同步的 PDO 是由 SYNC 信号触发，而异步的 PDO 是由节点内部的条件或其他外部条件触发。例如若一个节点规划为允许接受其他节点产生的 TPDO 请求，则可以由其他节点送出一个没有数据但有设置 RTR 位元的 TPDO（TPDO 请求），使该节点送出需求的数据。

借由 RPDO 也可以使两种设备同时启动。

CANopen 专有名词

PDO 过程数据对象 - 对应实际物理量的输入及输出。数据的单位可能是 RPM, V, Hz, mAmp...。

SDO 服务数据对象 - 一般来说是组态设定的数据，如节点位置、节点ID、通信速度、位移、增益等。……

COB-ID - CAN 对象编号

CAN ID - CAN Identifier. 是在每个 CAN 数据前面的信息识别码，共 11 位元。

EDS - 电子数据手册（Electronic data sheet）是 INI 格式或XML格式（从2007年底开始）的文件。

DCF - 设备配置文件（Device configuration file），是加强版的 EDS，可以设置节点 ID 及通信速度。

更多协议介绍，请参考：

CANopen应用程序框架图

CANopen最小程序开发流程图；

CANopen源代码框架图（SO-877-VP或SO-1063-VP）；

截止2016年12月31日，在CiA官方网站上列出的协议如下：

其中Status为

1、public的为公开协议；

2、DS (draft standard) DS (标准草案)

这种标准尚未定案，但已发布。 CiA 的标准草案在一年内不会发生改变。

3、DSP (draft standard proposal) DSP (标准草案提案)

这种标准仅是一个提案，但已发布。CiA的标准草案提案可随时变更，不事先通知。