CANopen在主机遥控系统中的应用

陈迪秋,　汪孔伟

(上海船舶运输科学研究所 航运技术与安全国家重点实验室，上海 200135)



CANopen在主机遥控系统中的应用

陈迪秋,汪孔伟

(上海船舶运输科学研究所 航运技术与安全国家重点实验室，上海 200135)

针对主机遥控系统的通信要求，提出CANopen协议在主机遥控系统中应用的方案。介绍冗余总线管理方案、活动主站确定方法、各通信对象在冗余CAN总线上的通信方式、以及针对主机遥控系统的虚拟设备的设计。该方案在主机遥控系统中应用是可行的,可满足主机遥控系统的通信功能需求及对实时性和可靠性的要求。

主机遥控系统；CANopen；分布式控制系统

1　概　述

CANopen自诞生以来,经过20多年的发展，现已成为由数十个规范组成的庞大体系，大致可分为以下几类：

(1) 通信规范和框架：定义通信对象的内容和通信机制；

(2) 设备规范：规定某一类型设备的对象字典和行为；

(3) 应用规范：定义一个基于CANopen的特定应用中的所有通信对象和应用对象；

(4) 其他规范：规定与CANopen相关的其他内容，如CANopen设备指示灯的定义、SI单位表示法等；

(5) 应用要点和推荐方法：提出CANopen应用中的注意事项。

将CANopen应用于主机遥控系统，可提高系统的可靠性、可维性和开放性。这里以某型主机遥控系统为目标系统，提出CANopen在该系统中应用的方案。该方案主要包括以下两方面内容:

(1) 通信方案，主要涉及冗余网络的管理、网络主站的确定以及网络上各通信对象的收发策略；

(2) 针对主机遥控系统的应用需求设计逻辑设备和虚拟设备。

2　通信方案的确定

目标主机遥控系统的原理框图见图1。

该系统面向低速二冲程船用柴油机设计，主要功能包括主机启动、停车、换向、调速、主机安保、主机状态监测及车令通信等。系统的通信网络采用2路冗余CAN总线，在网络上需要实现的功能包括冗余网络管理、实时数据通信、动作同步、网络管理、节点状态监测、参数修改、故障报警及对时服务等。

2.1CANopen设备模型

每个网络节点都是1个CANopen设备，冗余网络的CANopen设备模型[1]见图2。

图1　目标主机遥控系统原理框图

图2　CANopen设备模型

CANopen设备包含2个独立的CAN收发器和控制器，且在2路CAN上分别实现了NMT从站状态机，但需将其整合成1个节点状态；每个设备有且仅有1个对象字典和1个节点号。应用程序是实现设备主要业务功能的代码，通过编程接口与CANopen协议栈交换数据。

2.2冗余网络管理[1]

将系统中2路冗余CAN总线中的一路标记为默认CAN总线(Default CAN line)，另一路标记为冗余CAN总线(Redundant CAN line)。在2路CAN总线中，任意时刻有且仅有1路为活动CAN总线(Active CAN line)。

活动总线的切换逻辑见图3，其中：“(1)”表示在“心跳评估时间”内接收到所有节点的心跳报文；“(2)”表示在“心跳评估时间”内未接收到所有节点的心跳报文；“(3)”表示在默认总线上检测到1个节点的心跳丢失；“(4)”表示在默认总线上连续3次接收到所有节点的心跳；“(5)”表示在冗余总线上接收到“标识活动总线”报文；“(6)”表示在默认总线上接收到“标识活动总线”报文。

2.3实时数据通信

实时数据通信采用过程数据对象(Process Data Object，PDO)协议[1,3]。

1) PDO在2个网络上都发送。

2) PDO只允许在最大发送延迟时间(对象字典对象1F60h)内发送，超时未发送的PDO取消发送。

3) 定义PDO屏蔽时间，即PDO的最小发送间隔。

4) 在缺省总线上定义“通道错误计数器”，该计数器的最小值为0，最大值为“故障计数器阈值”(对象字典条目1F60h/04h)。若在缺省总线上无法在最大发送延迟时间内成功发送PDO，则通道错误计数器加4；若在缺省总线上成功发送PDO，则通道错误计数器减1。若通道错误计数器的值达到阈值，则节点停止在缺省总线上发送心跳，并在冗余总线上发送“指示活动CAN总线”报文。当通道错误计数器为0时，重新开始在默认总线上发送心跳(当在默认总线上重新检测到节点心跳时，切换触发活动总线)。

5) 2路总线上接收到的RPDO均进行处理。

6) 根据CiA 301为各RPDO定义事件定时器，若在规定时间内未接收到RPDO，则通知本地应用程序进行相应处理。

2.4动作同步[1,3]

若要实现某些操作(如启动、停车、慢转、空气运行等)需要多个模块同时进行相应操作。这里使用CiA 301定义的SYNC协议来实现动作同步。各模块在接收到需要同步动作的指令后不是立即执行，而是在接收到下一个同步报文时再同时开始执行相应操作。

SYNC报文由主站发送，由于其优先级较高，因此仅在活动总线上传输。

2.5网络管理

网络管理采用CiA 301定义的NMT协议，实现节点状态的切换。

根据CiA 307，在每个总线上实现独立的NMT从站状态机，最终节点的状态按照表1的规则确定。

图3　活动总线切换逻辑

冗余/活动线路冗余线路初始化运行准备运行停止活动线路初始化初始化运行准备运行停止运行准备运行准备运行准备运行停止运行运行运行运行停止停止停止停止停止停止

在各路CAN总线上执行的NMT服务(“NMT重置节点”服务除外)只改变该总线上的NMT状态;在各路CAN总线上执行的“NMT重置节点”服务都将重置2路总线上的NMT状态机。

无论何时,CANopen网络中只能有1个NMT主站。为实现NMT主站功能的冗余，可在多个NMT主站功能设备(NMT Master Capable Device)上部署NMT主站功能。

根据CiA 302，确定NMT主站的过程称为Flying Master过程。通过该过程可以在具有多个NMT主站功能设备的网络中确定一个起作用的NMT主站,具体过程见图4[2]。在目标主机遥控系统中使用各控制面板作为主站功能设备。

图4　Flying Master过程

2.6节点状态监测

CiA 301定义了2种节点状态监测协议,即节点保护(Node Guard)和心跳(Heartbeat)。目标系统的网络节点状态监测采用心跳作为节点状态监测协议[1,4]。

心跳生产者在2路冗余CAN网络上发送心跳报文，心跳消费者在2路冗余CAN网络上分别接收和处理心跳报文。心跳消费者在心跳消费时间内没有接收到所关注的心跳报文时，将产生心跳事件并通知本地应用程序进行处理。

2.7参数修改

各网络节点均有可设定的参数保存在EEPROM中，并可通过CAN网络进行修改。起作用的参数所在的区域称为工作区，暂时存储下载参数的区域称为缓存区。参数修改的流程如下：

(1) 下载参数至缓存区；

(2) 验证下载的参数；

(3) 使能新参数，将所有修改的参数复制到工作区；

(4) 固化参数至EEPROM。

设计对象字典时要考虑缓存区;规定工作区对象索引必须为偶数，该索引加1为其对应的缓存区。例如：若对象6000h为工作区对象，则对象6001h为其所对应的缓存区对象。

引入一个新制造商定义对象2000h，用于使能新参数(见表2)。

表2　使能新参数对象

下载或验证参数使用CiA 301定义的SDO协议,其中:下载参数使用SDO下载服务;验证下载的参数使用SDO上传服务。固化参数使用CiA 301定义的“1010h保存参数”对象。

为增强系统的安全性，引入权限控制对象2001h(见表3)。权限分为4级，每级可以修改的参数集各不相同；仅有在获得相应权限后才能修改对应的参数集。

2.8故障报警

故障报警使用CiA 301定义的EMCY协议。EMCY生产者在2路冗余CAN总线上发送EMCY报文;EMCY消费者在2路CAN总线上接收并处理EMCY报文。

2.9对时服务

对时服务使用CiA 301定义的TIME协议。TIME生产者在2路冗余CAN总线上发送TIME报文;TIME消费者仅处理活动总线上的报文。

3　逻辑设备/虚拟设备设计

逻辑设备是对现场设备的抽象，包括对象字典对象和设备基本功能定义。1个CANopen设备中最多可以部署8个逻辑设备，每个逻辑设备拥有的对象字典索引范围见表4。

表3　权限控制对象

表4　逻辑设备对象分配

每个逻辑设备又可以包含若干个虚拟设备。虚拟设备是现场设备内实现某一功能的软件实体，可看作是软件模块。其定义包括一系列对象字典对象和软件功能描述。虚拟设备既可部署在多个物理设备上，通过CAN总线交换数据；也可部署在同一设备上，通过内部接口交换数据。

主机遥控系统中各模块的电压/电流/开关量采集和输出功能可实现为1个逻辑设备，该逻辑设备采用CiA 401定义的一般I/O设备模型。

针对主机遥控系统应用，设计测速设备、工况状态机、转速控制器、主机安保设备及控制权管理器等虚拟设备。

(1) 测速设备可设置传感器类型及测速算法等参数，并通过对象字典提供转速测量值；

(2) 工况状态机根据车令和其他设定维护柴油机运行工况，并向各相关设备发送控制指令；

(3) 转速控制器根据设定来调节柴油机转速；

(4) 主机安保设备根据设定的控制逻辑执行紧急停车、故障停车和故障降速，保障主机安全运行；

(5) 控制权管理器负责维护控制位置及处理控制权转移请求。

4　结　语

针对主机遥控系统的通信要求提出了CANopen协议在主机遥控系统中应用的方案，包括冗余总线管理方案、活动主站确定方法、各通信对象在冗余CAN总线上的通信方式以及针对主机遥控系统的虚拟设备的设计等。该方案在主机遥控系统上应用是可行的，可满足主机遥控系统的通信功能需求以及对实时性和可靠性的要求。

[1]CiA. CiA 307, Framework for Maritime Electronics v1.0.1[S].

[2]CiA. CiA 302, Framework for CANopen Managers and Programmable CANopen Devices v3.2.1[S].

[3]CiA. CiA 301, CANopen application layer and communication profile v4.2.0[S].

[4]CiA. CiA Application Note 802, CAN Remote Frame: Avoid of Usage v1.1.0[S].

CANopen for Engine Remote Control System

CHEN Diqiu，WANG Kongwei

(StateKeyLaboratoryofNavigationandSafetyTechnology，ShanghaiShip&ShippingResearchInstitute，Shanghai200135，China)

A CANopen-based data format for communication within the engine remote control system is proposed. The management of redundant network, the determination of the active master node, the communication schemes for each communication object on the redundant network and the design of virtual devices for remote control application are also covered.

engine remote control system; CANopen; distributed control system

2015-11-09

陈迪秋(1986—)，男,福建福州人,助理研究员,主要从事船舶自动化技术研究。

1674-5949(2016)01-035-05

TP872;U664.821

A