CANopen是一种架构在控制局域网络（Controller Area Network, CAN）上的高层通信协议，包括通信子协议及设备子协议，常在嵌入式系统中使用，也是工业控制常用到的一种现场总线。

CANopen是一种架构在控制局域网路（Controller Area Network, CAN）上的高层通讯协定，包括通讯子协定及设备子协定常在嵌入式系统中使用，也是工业控制常用到的一种现场总线。

CANopen 实现了OSI模型中的网络层以上（包括网络层）的协定。CANopen 标准包括寻址方案、数个小的通讯子协定及由设备子协定所定义的应用层。 CANopen 支持网络管理、设备监控及节点间的通讯，其中包括一个简易的传输层，可处理资料的分段传送及其组合。一般而言数据链结层及物理层会用CAN来实作。除了 CANopen 外，也有其他的通讯协定（如EtherCAT）实作 CANopen 的设备子协定。

CANopen由非营利组织CiA（CAN in Automation）进行标准的起草及审核工作，基本的 CANopen 设备及通讯子协定定义在 CAN in Automation (CiA) draft standard 301中。针对个别设备的子协定以 CiA 301 为基础再进行扩充。如针对 I/O 模组的 CiA401 及针对运动控制的 CiA402。

以下是所有 CANopen 设备都要具备的功能：

通讯单元 处理和网络上其他模组通讯所需要的通讯协定。 设备的启动及重置由状态机(state machine)控制。状态机需包括以下的几个状态：Initialization, Pre-operational, Operational 及 Stopped。当接收到网络管理 (NMT) 通讯对象，状态机会转换到对应的状态。 对象字典 (Object Dictionary) 是一个有 16 位元索引 (Index) 的变量阵列。每个变量可以（但非必须）有 8 位元的子索引 (Subindex)。变量可用来调整设备的组态，也可以对应设备量测的资料或设备的输出。 当状态机设定为 operational　之后，设备的应用 (application) 部份就会实现设备预期的机能。此部份可以由对象字典中的变量调整其设定，而资料由通讯层传送或接收。

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的标准草案提案可随时变更，不事先通知。