CAN总线开发一本全（5） -CANopen协议概述

CAN总线开发一本全（5） -CANopen协议概述

本文精翻了CiA对CANopen协议的背景知识介绍，并根据个人的理解，调整了组织方式。

引言

CAN总线外设驱动程序能够提供基本的操作硬件电路系统的服务，但在具体的应用系统中，更多是基于协议栈开发上层应用，而不是针对某个具体的芯片平台编写定制的应用程序。目前CANopen是工业自动化领域最常用的CAN协议栈标准之一，它包含了高层的交互协议和配置文件规范，用于构建高度灵活配置能力的标准化嵌入式网络。CANopen使开发人员从处理CAN硬件特定细节（如位计时和接收过滤）中解脱出来，它使用标准化的通信对象（Communication Objects, COB），处理关注时效的进程、配置过程以及管理网络。

CANopen的发展历史

1994年11月，CiA发布了CANopen规范的第一个版本，CiA 301。这是最成功的Esprit研究项目之一。CANopen成功的故事是独一无二的，因为它不是由一家大型供应商推动的，而是由许多中小型公司以及机器制造商共同推动的。

最初，CANopen规范被命名为“工业系统基于CAL的通信配置规范”。它是在Esprit（欧洲信息技术研究战略计划，European Strategic Program on Research in Information Technology）的支持下开发的。编号为7302项目的标题是ASPIC，是“使用接入总线概念的生产单元的自动化和控制系统（Automation and Control Systems for Production Units using an Installation Bus Concept）”的缩写，目标是开发控制体系结构和设备，可以将现有的制造单元以灵活和模块化的方式组合起来。由Mohammad Farsi博士（纽卡斯尔大学）和Stefan Reitmeier博士（博世）领导的研究团队决定使用由CiA开发的CAN应用层（CAL）协议作为基础。CAL是一种基于OSI（Open Systems Interconnection）的纯应用层的模型。然而，在某些方面，它仅仅是一种来自不同方向的设计人员提出的学术方法，它的主要贡献来自Tom Suters（飞利浦医疗系统），以及Konrad Etschberger教授博士和Wolfhard lawrence教授博士，他们都在德国大学从事应用科学工作。当然，其他CiA成员也提出了想法。

ASPIC项目的目标是开发一个易于实现的应用层，专门用于控制嵌入式设备。在Bosch的领导下，几家公司（Moog、ADL Automation和J.L. Automation）和研究所（纽卡斯尔大学和Reutlingen应用科学大学）定义了今天被称为CANopen的第一个版本，主要贡献者是Mohamad Farsi博士和Gerhard Gruhler教授。第一个版本已经定义了PDO（流程数据对象，Process Data Object）和SDO（服务数据对象，Service Data Object），引入了PDO的同步传输以及网络管理(NMT)和紧急消息。

在CANopen发展过程的早期，使用CAN远程帧发起数据请求的方式仍然是做常用的做法，CAN网络管理中的节点保护机制（Node Guarding）就是基于它实现的，不过节点保护机制在后来被心跳机制所取代。最初的CANopen网络也使用远程请求实现PDO。现在，CiA建议完全不要使用远程帧。

CANopen可以看作是中小供应商的应用层，它是一个不是由一个市场主导的、独立的工业通信系统。它也可以被看作是系统设计人员的解决方案，因为一些设备制造商已经选择了独立于供应商的这种方法完成设计，这些机器制造商包括了Heidelberger和Siemens Healthcare。1995年，CiA在其汉诺威博览会上展示了最早的CANopen演示方案，整合了Moog、Selectron和其他供应商的产品。

作为CiA 301发布的CANopen规范，是最成功的Esprit研究项目之一。该规范被移交给CiA进行进一步的开发和维护。一开始，一些公司在现实应用中实现了高层协议。后来，经过进行一些审查和更新，CANopen逐渐成为一个稳定的规范。3.0版本是第一个用于产品和系统的版本。这个版本从1996年到1999年有效，一些应用程序至今仍在使用这个版本。

表x CANopen发展大事记

时间	事件
1993年	Bosch领导的Esprit项目开始启动对CANopen的早期开发。
1994年	发布基于CAL的通信规范，作为CANopen的最初版本 1.0
1995年	发布CiA 301，CANopen应用层和通信规范 2.0
1996年	发布CiA 301，CANopen应用层和通信规范 3.0
1999年	发布CiA 301，CANopen应用层和通信规范 4.0（EN 50325-4）
2007年	发布CiA 301，CANopen应用层和通信规范 4.2（仅面向CiA成员）
2011年	发布CiA 301，CANopen应用层和通信规范 4.2（面向公众）

CANopen的底层

CANopen的数据链路层基于ISO 11898-1的CAN总线。CiA 301中指定了CANopen位计时规范，允许数据速率从10k bsp调整到1M bps。虽然所有指定的CAN-ID寻址模式都基于11位的CAN-ID，但CANopen也支持29位的CAN-ID。CANopen根据ISO 11898-2对物理层进行了抽象，但同时，CANopen也并不排除其他可能使用的物理层。

CANopen的数据链路层基于ISO 11898-1的CAN总线。尽管大多数寻址模式都基于基本帧格式，但CANopen也支持扩展帧格式。直到CANopen版本CiA 301 V4.2, CANopen只支持经典的CAN。从CiA 301 V5.0版本开始，CANopen是基于CAN FD的。

表x罗列了CANopen位时间对应总线最大长度和设备间电缆接线最大长度。总线网络中的所有CANopen设备必须至少支持定义的比特率之一 ，当然，CANopen设备可以支持更多的比特率。采样点的位置必须尽可能接近87.5%的位时间周期中。

表x CANopen位时间对应总线最大长度和设备间电缆接线最大长度

比特率	总线长度	设备间电缆接线最大长度	设备间电缆接线累计最大长度
1 Mbit/s	25 m	1.5 m	7.5 m
800 kbit/s	50 m	2.5 m	12.5 m
500 kbit/s	100 m	5.5 m	27.5 m
250 kbit/s	250 m	11 m	55 m
125 kbit/s	500 m	22 m	110 m
50 kbit/s	1000 m	55 m	275 m
20 kbit/s	2500 m	137.5 m	687.5 m
10 kbit/s	5000 m	275 m	1375 m

CANopen根据ISO 11898-2对物理层进行了抽象，但实际应用领域的环境要求可能不完全遵守ISO 11898-2，因此，CANopen也可以适配其他物理层。但若适配其他物理层，设计的CANopen设备无法接入标准的CANopen网络中。

CANopen设备的内部架构

标准化的CANopen设备和应用程序配置文件简化了集成CANopen系统的任务，能够方便地适配到现存的设备、工具和协议栈。对于系统设计人员来说，复用应用软件是非常重要的，这不仅要求兼容通信数据，而且要求设备能够相互操作甚至相互替换。CANopen设备、接口和应用程序配置文件使设备制造商能够为其产品提供标准化接口，从而在CANopen网络中实现具有“即插即用”功能的CANopen设备。不仅如此，CANopen还允许制造商继续扩展跟多专用功能。

CANopen将通信过程抽象成若干个对象，设备设计人员基于这些通信对象的实例，在具体设备中实现所需的网络行为。使用这些通信对象，设备设计人员可以赋予设备能够通信过程数据、指示设备内部错误情况，以及控制网络行为。设备设计人员也可以基于CANopen，使设备能够参与网络中的点对点通信。由于CANopen定义了内部设备结构，系统设计人员可以明确地知道如何访问CANopen设备以及如何调整对设备预期的行为。

一个CANopen设备包含三个逻辑部分：

• CANopen协议栈处理通过CAN总线网络的通信
• 应用软件提供了内部的控制功能以及访问硬件的接口
• CANopen的对象字典为协议和应用软件提供接口。

CANopen的对象字典（Object Dictionary）对于CANopen设备配置和诊断是至关重要的，其中包含所有使用的数据类型的引用（索引），并存储所有通信和应用程序的配置参数。设备内部的引用使用一个以4位16进制值表示16位数值的索引。其中，0x1000到0x1FFF的索引范围，定义了CANopen设备中所有CANopen通信行为的参数。如表x所示。

表x CANopen对象字典的索引空间

索引值	功能说明
0x0000	保留未使用
0x0001 - 0x025F	数据类型
0x0260 - 0x0FFF	保留未使用
0x1000 - 0x1FFF	通信对象区域，专有参数
0x2000 - 0x5FFF	制造商专用区域，专有参数
0x6000 - 0x9FFF	设备配置专属区域，标准化参数
0xA000 - 0xBFFF	接口配置专属区域
0xC000 - 0xFFFF	保留未使用

定义CANopen对象字典的意义在于，任何CANopen设备都支持统一的SDO服务，系统设计人员就可以基于约定，通过网络配置各设备中的对象字典，进而指定的CANopen设备行为。

CANopen的协议栈

CANopen协议栈包含了若干个协议：

• SDO协议（服务数据对象，Service Data Object）
• PDO协议（过程数据对象，Process Data Object）
• NMT协议（网络管理，Network Management）
• 专用功能协议（Special Function）
• 错误控制协议（Error Control）

每个CANopen协议实现了若干个通信对象（Communication Object）。系统设计人员使用CANopen通信对象传递控制信息，对某些错误状态作出反应，以及控制网络行为。通过在CANopen对象字典中检查是否存在描述通信行为的相关条目，以评估CANopen设备的能力。

SDO协议

SDO（服务数据对象，Service Data Object）允许访问CANopen对象字典的所有条目。一个SDO由两个具有不同标识符的CAN数据帧组成，可以在CAN总线网络上建立两个CANopen设备之间的点对点的“客户端-服务端”通信。被访问对象字典的所有者充当SDO的服务端，访问另一个设备的对象字典的设备是SDO客户机。如图x所示。

图x SDO协议通信过程

CANopen设备可以支持不同的SDO协议变种：快速传输、常规（分段）传输或块传输。

在初始化过程中，客户端设备指示将从服务端的对象字典中访问哪些信息，使用哪种SDO类型，以及是否要读取或写入信息。服务端设备回应查询请求给客户端设备。然后，客户端设备开始传输第一个数据段。常规传输允许以分段的方式传输任意数量的数据，每个段最多可以携带7个字节的应用程序数据，1个字节需要用于协议信息，总共8个字节封装进入CAN通信帧的数据负载。在正常的SDO传输中，可以交换无限数量的段，即可以交换无限数量的应用程序数据，如图x所示。

图x SDO协议的常规传输

除了基本的常规传输，SDO还可以使用快速传输和块传输分别提升不同数据负载情况下的传输效率。使用快速SDO传输可以加速小数据负载（小于或等于4字节）的SDO传输，此时，在SDO连接启动期间可以直接传输数据。使用SDO块传输可以加速大数据负载的传输，此时，接收端不会确认单个数据段（像常规传输过程一样)，而是只是在一个数据块（最多127个段）传输完成后应答确认。设备制造商可以根据设备传输数据的体量，决定在实现何种SDO的传输方式。

CANopen设备可以支持SDO客户端或服务端的多个通道。如果设备支持SDO客户端通道，则该设备能够访问其他连入网络设备的对象字典。如果设备支持服务端通道，则设备可为其他连入网络的设备提供访问自身的对象字典条目的机会。设备制造商在设计设备时，必须确认他们的设备是否需要访问其他设备，或者被其他设备访问，然后，再确认需要实现多少个SDO客户端和服务端的通道。第一个SDO服务端通道已经预先由规范严格定义，并且必须在所有CANopen设备上实现。

SDO参数清单位于对象字典索引范围0x1200 ~ 0x12FF，其中，SDO服务端通道的参数位于从0x1200到0x127F，SDO客户端通道的参数位于0x1280F到0x12FF的范围内提供。SDO参数清单包含两个通信对象ID（communication object identifier，COB-ID）和相关通信节点的节点ID（Node-ID）。COB-ID条目涵盖了用于在服务端到客户端方向上和客户端到服务端方向上传输信息的CAN帧的ID。如表x所示。

表x 一个SDO参数清单条目

对象字典中的索引	次级索引	功能描述
0x12xx	0x00	通道入口编号
	0x01	客户端到服务端的通信对象ID
	0x02	服务端到客户端的通信对象ID
	0x03	客户端和服务端的节点ID

PDO协议

CANopen使用过程数据对象（Process Data Object，PDO）广播高优先级的控制和状态信息。PDO由一个CAN帧组成，传输最多8字节的纯应用程序数据。设备设计人员必须评估设备需要接收和传输的处理数据量，以此确认在设备内提供对应数量的接收和发送PDO。

当设备支持PDO的传输/接收时，需要在该设备的对象字典中提供该PDO相应的参数清单。一个PDO需要一组通信参数和一组映射参数。其中，通信参数指示此PDO使用的CAN通信帧的ID，以及相关PDO传输的触发事件。映射参数表示应该传输本地对象字典中的哪些信息，以及将接收到的信息存储在何处。

接收PDO的通信参数设置在索引范围0x1400 到0x15FF，发送PDO的通信参数设置在索引范围0x1800 到0x19FF。对应的映射项在索引范围分别在0x1600h到17FF和0x1A00到0x1BFF。

在PDO的触发事件定义了如下内容：

• 事件或定时器驱动：设备内部事件触发PDO传输（例如，当温度值超过某个限制或者某个定时器超时等等）。
• 远程请求：由于PDO由单个CAN数据帧组成，因此可以通过远程传输请求（RTR）请求它们。
• 同步传输（循环）：PDO的传输可以耦合到SYNC消息的接收。
• 同步传输（无循环）：这些PDO可由具体设备的事件触发，但与下一个同步消息的接收一起传输。

图x PDO协议的触发事件

PDO映射定义了PDO中传输哪些应用程序对象。它描述映射的应用程序对象的顺序和长度。应用程序对象的映射在每个PDO的相关CANopen对象字典条目中描述。CANopen区分了三种类型的PDO映射：

• 静态PDO映射：静态PDO映射描述了PDO的内容由设备制造商预定义，不能通过CANopen接口更改。
• 可变PDO映射：可变PDO映射描述了PDO的映射项可以在NMT预操作状态下更改。
• 动态PDO映射：动态PDO映射描述了PDO映射项在NMT运行状态下也可以改变。

图x PDO映射

除去已经预定义的映射，设备设计人员可以选择更改部分PDO的映射。在CANopen中，这种灵活可调的PDO映射能力称为可变PDO映射或动态PDO映射。在支持可变映射或动态映射的情况下，PDO的映射项只能通过使用定义的映射过程来更改：

1. 通过切换相关COB-ID表项中的31位，将PDO设置为无效。
2. 通过将0x00写入相关映射项的子索引0x00h，将PDO映射设置为无效。
3. 调整所需的PDO映射。
4. 将对应映射索引的子索引0x00h设置为映射对象个数。
5. 切换PDO为有效，操作相关COB-ID条目中第31位。

MNT协议

所有CANopen设备都需要支持CANopen网络管理（NMT，Network Management）从机。NMT的状态机定义了CANopen设备的通信行为。CANopen NMT状态机由初始化状态（Initialization state）、预操作状态（Pre-operational state）、操作状态（Operational state）和停止状态（Stopped state）组成：

• 设备上电或复位后，进入“初始化”状态。设备初始化完成后，会自动过渡到预操作状态，并发送启动消息通知，表明它已经准备好工作了。
• 处于预操作状态的设备可以开始传输同步消息、时间戳消息或心跳消息，前提是这些服务得到了支持并且配置正确。此状态下，设备可以通过SDO进行通信，但不能使用PDO通信（PDO通信只能在操作状态下进行）。
• 在操作状态下，设备可以使用所有支持的通信对象。
• 设备在切换到停止状态时，仅对接收到的NMT命令作出反应。此外，在停止状态下，设备通过支持错误控制协议来指示NMT的当前状态。

图x NMT的状态机

初始化状态包括初始化、重置应用程序和重置通信三种子状态。在初始化过程中，设备启动并初始化其内部参数。引入了两个子状态，重置应用程序和重置通信，来启用部分重置命令。在重置应用程序期间，对象字典中从0x2000到0x9FFF的所有参数都被设置为上电默认值。在上电后，自动进入NMT子状态重置通信，通信配置文件的参数（索引范围0x1xxx）被设置为它们的上电默认值，之后，离开初始化状态。

CANopen网络中，由激活的NMT主机发起NMT传输，运行NMT协议的从机必须接收NMT命令，进入NMT状态机。NMT协议采用一个数据长度为2字节的CAN帧，第一个字节包含命令说明字，第二个字节包含必须执行命令的设备的节点ID（如果该值等于0，则所有节点都必须执行命令状态转换）。NMT协议帧使用0号CAN标识符，这是CAN总线系统中最高的优先CAN-ID。

图x NMT的消息帧

特殊功能协议

CANopen提供了三个特定的协议来处理特殊的网络行为：

• 同步协议（SYNC）使网络行为同步。
• 时间戳协议（Time-stamp）用于调整统一的网络时间。
• 紧急协议（Emergency）可用于通知其他网络参与者设备内部错误。

同步协议由同步消息生产者周期性地输出，两个连续的同步消息之间的时间周期为通信周期。同步消息使用ID为0x80的单CAN帧。默认情况下，同步消息不携带任何数据（DLC = 0，CAN帧的数据负载长度为0）。支持CiA 301 v4.1或更高版本的设备可以选择附加一个SYNC消息，提供一个1字节的同步计数器值。使用同步协议，可以更方便地协调多个设备的同步行为。

图x CANopen的同步协议

时间戳协议允许CANopen系统的用户调整到统一的网络时间。时间戳消息是一个数据长度为6字节的CAN帧，这6个字节的数据提供了时间信息，从1984年1月1日开始计日，以午夜0点开始计毫秒。缺省情况下，这个CAN帧的CAN标识符为0x100。

图x CANopen的时间戳协议

紧急消息可由设备内部的错误事件触发。由紧急事件的发生者传输的紧急消息是一个CAN帧，该帧最多包含8字节的数据，数据内容定义为1字节错误寄存器（本地对象字典的索引0x1001）、16位紧急错误代码和最多5字节的特定于制造商的错误信息。默认情况下，可以产生紧急消息的设备将CAN标识符0x80h + (节点ID)分配给紧急消息。对每个错误事件只传输一次紧急消息，只要设备上没有出现新的错误，就不会再发送任何紧急消息。零个或多个紧急消息的接受者可能会收到这些消息，并可能启动合适的、特定于应用程序的对策措施。

图x CANopen的紧急协议

错误控制协议

错误控制协议用于监控CANopen网络，包括心跳协议（Heartbeat protocol）、守护协议（Guarding protocol）以及启动协议（Boot-Up protocol）。

心跳协议用于验证所有网络参与者在CANopen网络中仍然可用，并且它们仍然处于预期的NMT状态机中。在老式的CANopen系统中，使用CAN远程帧，而不是心跳协议，来实现守护协议。但现代的CAN不再推荐使用基于CAN远程帧的服务。所有的错误控制协议都基于相同的CAN消息，其中CAN帧标识符为0x700 +要监控的CANopen设备的节点ID。

心跳协议是一个定期传输的消息，由心跳消息的发送者通知所有心跳消息的接收者，自己仍在正常工作。此外，心跳协议还提供了心跳消息发送者的当前NMT状态。心跳消息的传输周期可以在对象字典索引0x1017中配置。

保护协议是一种过时的方法，用于检查受保护的CANopen设备是否仍在正确的网络状态下工作，这是一个基于CAN远程帧的服务（CiA不建议使用CAN远程帧，因为远程帧带来的麻烦远比它能够解决的问题多），后来被心跳协议所取代。例如，在老式的应用程序中，主控制器通过CAN远程帧请求被监控CANopen设备的错误控制信息，每个被管控的设备回应一个CAN数据帧，表示当前NMT状态。

启动协议表示一种特殊类型的错误控制协议。在NMT初始化状态之前，它作为NMT预操作状态前的最后一个传输动作，接收到此消息表明新设备已经注册到CANopen网络。如果在运行期间意外接收到这样的协议，要么表明网络设置发生了变化（例如，添加了新的CANopen设备），要么被认为是错误条件的标志（例如，某些CANopen设备的错误上电)。该协议使用与任何其他错误控制协议（例如心跳协议）相同的CAN帧标识符，1字节的数据字段使用一个固定的值0。

CANopen制造商ID

每个CANopen设备需要包含一组标识参数，其中就包含了CANopen制造商ID（CANopen Vendor-ID）。CiA定义这个制造商ID为一个32位的数值。对于CiA成员，这个制造商ID是可以免费申请的。

CANopen v4.0和EN 50325-4要求，CANopen的制造商ID用于标识CANopen产品的制造商（商业公司或大型组织的部门）。所有的制造商ID均由CiA分配。

CANopen制造商ID是CANopen设备的标识参数的一部分，标识参数充当全球唯一的设备地址。一些服务（例如LSS和节点声明）利用这个参数来正确识别CANopen设备，允许即插即用，并检查整个系统的完整性。

图x CANopen的制造商ID

CANopen制造商ID也可以用于其它通信技术机构。表x中记录了制造商ID的分配区间。

表x CANopen制造商的分配区间

CANopen制造商ID	组织机构
0000 0000h to AFFE FFFFh	CAN in Automation (CiA)
AFFF 0000h to FFFE FFFFh	reserved
FFFF 0000h to FFFF 0FFFh	Ethernet Powerlink Standardization Group (EPSG)
FFFF 1000h to FFFF FFFFh	reserved

例如，NXP在其中的制造商ID为0x000002DC，Infineon为0x0000034E，Bosch为0x00000477。

参考文献

• CANopen协议诞生及发展, https://www.elecfans.com/application/Communication/633054.html
• CANopen – The standardized embedded network, https://www.can-cia.org/canopen/
• CANopen history, https://www.can-cia.org/can-knowledge/canopen/canopen-history/
• CANopen lower layers，https://www.can-cia.org/can-knowledge/canopen/canopen-lower-layers/
• Service data object (SDO)，https://www.can-cia.org/can-knowledge/canopen/sdo-protocol/
• Process data object (PDO)，https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/
• Network management (NMT)，https://www.can-cia.org/can-knowledge/canopen/network-management/
• Special function protocols，https://www.can-cia.org/can-knowledge/canopen/special-function-protocols/
• Error control protocols，https://www.can-cia.org/can-knowledge/canopen/error-control-protocols/
• CANopen vendor-ID，https://www.can-cia.org/services/canopen-vendor-id/