电子发烧友App
引言
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发展大事记
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位时间对应总线最大长度和设备间电缆接线最大长度
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对象字典的索引空间
定义 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 所示。
figure-canopen-sdo-protocol
图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参数清单条目
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 可由具体设备的事件触发，但与下一个同步消息的接收一起传输。
figure-canopen-pdo-triggering-events
图x PDO协议的触发事件
PDO 映射定义了 PDO 中传输哪些应用程序对象。它描述映射的应用程序对象的顺序和长度。应用程序对象的映射在每个 PDO 的相关 CANopen 对象字典条目中描述。CANopen 区分了三种类型的 PDO 映射：
- 静态 PDO 映射：静态 PDO 映射描述了 PDO 的内容由设备制造商预定义，不能通过 CANopen 接口更改。
- 可变 PDO 映射：可变 PDO 映射描述了 PDO 的映射项可以在 NMT 预操作状态下更改。
- 动态 PDO 映射：动态 PDO 映射描述了 PDO 映射项在 NMT 运行状态下也可以改变。
除去已经预定义的映射，设备设计人员可以选择更改部分 PDO 的映射。在 CANopen 中，这种灵活可调的 PDO 映射能力称为可变 PDO 映射或动态 PDO 映射。在支持可变映射或动态映射的情况下，PDO 的映射项只能通过使用定义的映射过程来更改：
- 通过切换相关 COB-ID 表项中的 31 位，将 PDO 设置为无效。
- 通过将 0x00 写入相关映射项的子索引 0x00h，将 PDO 映射设置为无效。
- 调整所需的 PDO 映射。
- 将对应映射索引的子索引 0x00h 设置为映射对象个数。
- 切换 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 的当前状态。
figure-canopen-nmt-slave
图x NMT的状态机
初始化状态包括初始化、重置应用程序和重置通信三种子状态。在初始化过程中，设备启动并初始化其内部参数。引入了两个子状态，重置应用程序和重置通信，来启用部分重置命令。在重置应用程序期间，对象字典中从 0x2000 到 0x9FFF 的所有参数都被设置为上电默认值。在上电后，自动进入 NMT 子状态重置通信，通信配置文件的参数（索引范围 0x1xxx）被设置为它们的上电默认值，之后，离开初始化状态。
CANopen 网络中，由激活的 NMT 主机发起 NMT 传输，运行 NMT 协议的从机必须接收 NMT 命令，进入 NMT 状态机。NMT 协议采用一个数据长度为 2 字节的 CAN 帧，第一个字节包含命令说明字，第二个字节包含必须执行命令的设备的节点 ID（如果该值等于 0，则所有节点都必须执行命令状态转换）。NMT 协议帧使用 0 号 CAN 标识符，这是 CAN 总线系统中最高的优先 CAN-ID。
figure-canopen-nmt-message
图x NMT的消息帧
特殊功能协议
CANopen 提供了三个特定的协议来处理特殊的网络行为：
- 同步协议（SYNC）使网络行为同步。
- 时间戳协议（Time-stamp）用于调整统一的网络时间。
- 紧急协议（Emergency）可用于通知其他网络参与者设备内部错误。
同步协议由同步消息生产者周期性地输出，两个连续的同步消息之间的时间周期为通信周期。同步消息使用 ID 为 0x80 的单 CAN 帧。默认情况下，同步消息不携带任何数据（DLC = 0，CAN 帧的数据负载长度为 0）。支持 CiA 301 v4.1 或更高版本的设备可以选择附加一个 SYNC 消息，提供一个 1 字节的同步计数器值。使用同步协议，可以更方便地协调多个设备的同步行为。
figure-canopen-sync-protocal
图x CANopen的同步协议
时间戳协议允许 CANopen 系统的用户调整到统一的网络时间。时间戳消息是一个数据长度为 6 字节的 CAN 帧，这 6 个字节的数据提供了时间信息，从 1984 年 1 月 1 日开始计日，以午夜 0 点开始计毫秒。缺省情况下，这个 CAN 帧的 CAN 标识符为 0x100。
figure-canopen-timestamp-protocal
图x CANopen的时间戳协议
紧急消息可由设备内部的错误事件触发。由紧急事件的发生者传输的紧急消息是一个 CAN 帧，该帧最多包含 8 字节的数据，数据内容定义为 1 字节错误寄存器（本地对象字典的索引 0x1001）、16 位紧急错误代码和最多 5 字节的特定于制造商的错误信息。默认情况下，可以产生紧急消息的设备将 CAN 标识符0x80h + (节点ID)分配给紧急消息。对每个错误事件只传输一次紧急消息，只要设备上没有出现新的错误，就不会再发送任何紧急消息。零个或多个紧急消息的接受者可能会收到这些消息，并可能启动合适的、特定于应用程序的对策措施。
figure-canopen-emcy-protocal
图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 设备，允许即插即用，并检查整个系统的完整性。
figure-canopen-vendor-id
图x CANopen的制造商ID
CANopen 制造商 ID 也可以用于其它通信技术机构。表 x 中记录了制造商 ID 的分配区间。
表x CANopen制造商的分配区间
工商网监
评论