CN109361586B - 一种CANopen从站的启动方法及其统筹管理器 - Google Patents

Abstract

本发明公开了一种CANopen从站的启动方法及其统筹管理器，启动方法包括：挨个判断所有从站的节点号是否在网络列表中；在从站的节点号在网络列表中时，判断是否允许启动从站；在从站的节点号未在网络列表中时，结束启动并伴随一个错误标识A；在允许启动从站时，执行步骤S30，判断从站的各项信息是否与主站中对应的元素一致；在未允许启动从站时，执行步骤S40，开始错误控制服务，判断从站是否启动成功，是则结束启动并伴随启动成功，否则复位从站，使从站跳转至等待启动状态；步骤S50，判断从站的配置是否正确，是则执行步骤S40，否则结束启动。本发明方便对从设备的管理，提高从设备差异类型的连接灵活性，提升了整体系统的动态性和可靠性。

Description

一种CANopen从站的启动方法及其统筹管理器

技术领域

本发明涉及通讯技术领域的一种从站的启动方法及其管理器，尤其涉及一种CANopen从站的启动方法及其统筹管理器。

背景技术

CAN是Controller Area Network的缩写，是ISO国际标准化的串行通信协议。CAN属于现场总线的范畴，它是一种有效支持分布式控制或实时控制的串行通信网络。同时，CAN的高性能和可靠性已被广泛认同，并被广泛地应用于工业自动化、船舶、医疗设备、工业设备等方面。

一个基于CAN总线的网络中有多个设备，其中的从站可能因为在分布式系统中扮演的角色有所差异，这样的差异需要进行差异化的启动和控制，单一的统一处理会降低设备之间连接的灵活性，不利于整个分布式系统任务的顺利运作。

发明内容

针对现有的技术问题，本发明提供一种CANopen从站的启动方法及其统筹管理器，以缓解现有技术中单一处理的弊端，实现从站的可选配置的启动，以便提高整体系统的动态灵活性和可靠性。

本发明采用以下技术方案实现：一种CANopen从站的启动方法，其应用于CAN总线上的多个设备，且其中一个设备为主站，其他设备为从站；

所述启动方法包括：

步骤S10，挨个判断所有从站的节点号是否在网络列表中；

在所述从站的节点号在网络列表中时，执行步骤S20，判断是否允许启动所述从站；

在所述从站的节点号未在网络列表中时，结束启动并伴随一个错误标识A；

在允许启动所述从站时，执行步骤S30，判断所述从站的各项信息是否与所述主站中对应的元素一致；

步骤S31，判断所述从站是否为活跃节点；

在所述从站为活跃节点时，执行步骤S32，先配置心跳消费者，后检查所述活跃节点的状态；配置心跳消费者的方法为：获取所述从站的心跳参数，根据所述从站的心跳参数设置所述主站的心跳参数；检查所述活跃节点的状态的方法包括：步骤S321，判断所述心跳消费者的心跳时间是否大于零；在所述心跳时间非零时，执行步骤S322，判断所述主站是否接收到心跳，是则结束检查状态，否则判断所述心跳消费者的心跳间隔是否超过一个预设时间一；在所述心跳间隔超过所述预设时间一时，结束检查状态并伴随一错误标识E；在所述心跳间隔未超过所述预设时间一时，执行步骤S322；在所述心跳时间等于零时，请求节点监护响应；步骤S323，判断所述主站是否接收到节点监护，是则结束检查状态，否则判断是否超时一个预设时间二，是则结束检查状态并伴随一错误标识F；

在所述活跃节点的状态为非运行状态时，复位所述活跃节点的通讯，并执行步骤S33，更新所述从站的软件程序至一个预设版本的程序；

在所述活跃节点的状态为运行状态时，执行步骤S40；

在所述从站为非活跃节点时，执行步骤S30；

在未允许启动所述从站时，执行步骤S40，开始错误控制服务，判断所述从站是否启动成功，是则结束启动并伴随启动成功标识，否则复位所述从站，使所述从站跳转至等待启动状态；

步骤S50，判断所述从站的配置是否正确，是则执行步骤S40，否则结束启动并伴随一个错误标识K。

进一步地，判断所述从站的各项信息是否与所述主站中对应的元素一致的方法包括：

请求访问所述从站的0x1000对象，并读取所述0x1000对象；

在所述从站首次回复时，判断首次回复的内容是否与所述主站的0x1F84对象中保存的内容一致，是则请求访问所述从站的0x1018对象，否则结束启动并伴随一个错误标识C；

在所述从站再次回复时，判断再次回复的内容是否与所述主站的0x1F85-0x1F88对象保存的内容一致，是则进行步骤S31，否则结束启动并伴随错误标识D、M、N、O；

在所述从站未回复时，结束启动并伴随一个错误标识B；

其中，所述0x1000对象、所述0x1018对象用于存储所述从站的各项信息。

再进一步地，所述从站的各项信息包括设备类型信息、厂家标识信息、产品编码信息、版本号信息、序列号信息；所述0x1000对象对应所述设备类型信息，所述0x1018对象的四个子项分别对应所述厂家标识信息、所述产品编码信息、所述版本号信息、所述序列号信息。

再进一步地，在步骤33中，判断所述从站是否需要被检查；

在所述从站需被检查时，检查和更新所述从站的版本，并判断所述从站的版本是否正确，是则执行步骤S50，否则结束启动并伴随错误标识G、H、I。

再进一步地，所述错误控制服务的控制方法包括：

步骤S401，判断心跳消费者的心跳时间是否大于零；

在所述心跳时间大于零时，执行步骤S402，判断所述主站是否接收到心跳；

在所述主站接收到心跳时，判定所述从站启动成功；

在所述主站未接收到心跳时，执行步骤S403，判断所述心跳消费者的心跳间隔是否超过一个预设时间三，是则伴随错误标识K，否则执行步骤S402；

在所述心跳时间等于零时，判断节点是否在网络列表中，是则判断监护时间是否大于零，否则判定所述从站启动成功；

在所述监护时间大于零时，先启动节点监护，若得到回复则判定所述从站启动成功；在所述监护时间等于零时，直接判定所述从站启动成功。

再进一步地，判断所述从站的配置是否正确的方法包括：

步骤S501，判断期望配置的日期及时间是否不为零；

在期望配置的日期及时间不为零时，请求访问0x1020对象，并判断响应是否等于期望值；

在期望配置的日期及时间为零时，执行步骤S502，更新配置；

在所述响应等于期望值时，结束配置并判定所述从站的配置正确；在所述响应不等于期望值时，执行步骤S502；

步骤S503，判断配置是否更新成功，是则结束配置并判定所述从站的配置正确，否则结束启动并伴随一个错位标识J。

作为上述方案的进一步改进，所述启动方法还包括：

在判定所述从站启动成功后，执行步骤S60，判断所述从站能否被运行；

在能够运行所述从站时，判断所述从站是否需要被独立运行，是则先使所述从站进入运行状态，后结束启动并伴随标识OK，否则判断所述主站是否处于运行态；

在所述主站处于运行态时，使所述从站进入运行状态；

在所述主站未处于运行态，或不能运行所述从站时，结束启动并伴随标识OK。

本发明还提供一种统筹管理器，其用于管理CAN总线上的多个设备中设置的多个模块；所述统筹管理器管理多个模块时，实现上述任意一项所述的CANopen从站的启动方法的步骤。

本发明的CANopen从站的启动方法及其统筹管理器，可以实现对CAN总线上的多个设备的启动，提高从设备差异类型的连接灵活性，提升了整体系统的动态性和可靠性。

附图说明

图1为本发明实施例1的CANopen从站的启动方法的第一部分的流程图；

图2为本发明实施例1的CANopen从站的启动方法的第二部分的流程图；

图3为本发明实施例1的CANopen从站的启动方法的第三部分的流程图；

图4为本发明实施例3的统筹管理器的模块结构图；

图5为本发明实施例3的统筹管理器启动主站时的第一部分流程图；

图6为本发明实施例3的统筹管理器启动主站时的第二部分流程图；

图7为图4中的统筹管理器的模块轮询图；

图8为图4中的统筹管理器的状态机的第一部分的原理框图；

图9为图4中的统筹管理器的状态机的第二部分的原理框图；

图10为图4中的统筹管理器开始处理启动NMT从站的流程图；

图11为图4中的统筹管理器检查配置的流程图；

图12为图4中的统筹管理器检查NMT状态的流程图；

图13为图4中的统筹管理器开始错误控制的流程图；

图14为图4中的统筹管理器使从站启动状态机的第一部分的流程图；

图15为图4中的统筹管理器使从站启动状态机的第二部分的流程图；

图16为图4中的统筹管理器使从站启动状态机的第三部分的流程图；

图17为图4中的统筹管理器使从站启动状态机的第四部分的流程图；

图18为本发明实施例3的AutoHb模块配置状态机的原理框图；

图19为本发明实施例3中启动命令、事件、协议和状态的流程图；

图20为图4中的统筹管理器启动处理的流程图；

图21为本发明实施例3中主站和多个从站相对应且在心跳机制下的对应图；

图22为本发明实施例3中主站和多个从站相对应且在生命周期机制下的对应图；

图23为本发明实施例3中NMTM表的组织结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

实施例1

请参阅图1、图2以及图3，本实施例提供了一种CANopen从站的启动方法，其应用于CAN总线上的多个设备，且其中一个设备为主站，其他设备为从站。

其中，启动方法包括：

步骤S10：挨个判断所有从站的节点号是否在网络列表中。

在从站的节点号在网络列表中时，执行步骤S20：判断是否允许启动从站。

在从站的节点号未在网络列表中时，结束启动并伴随一个错误标识A。

在允许启动从站时，执行步骤S30：判断从站的各项信息是否与主站中对应的元素一致。

步骤S31：判断从站是否为活跃节点。

在从站为活跃节点时，执行步骤S32：先配置心跳消费者，后检查活跃节点的状态。

在活跃节点的状态为非运行状态时，复位活跃节点的通讯，并执行步骤S33，更新从站的软件程序至一个预设版本的程序。

在未允许启动从站时，执行步骤S40：开始错误控制服务，判断从站是否启动成功，是则结束启动并伴随启动成功标识，否则复位从站，使从站跳转至等待启动状态。

在活跃节点的状态为运行状态时，执行步骤S40。

在从站为非活跃节点时，执行步骤S30。

步骤S50：判断从站的配置是否正确，是则执行步骤S40，否则结束启动并伴随一个错误标识K。

在判定从站启动成功后，执行步骤S60：判断从站能否被运行。

在能够运行从站时，判断从站是否需要被独立运行，是则先使从站进入运行状态，后结束启动并伴随标识OK，否则判断主站是否处于运行态。

在主站处于运行态时，使从站进入运行状态。在主站未处于运行态，或不能运行从站时，结束启动并伴随标识OK。

在本实施例中，判断从站的各项信息是否与主站中对应的元素一致的方法包括：请求访问从站的0x1000对象，并读取0x1000对象。在从站首次回复时，判断首次回复的内容是否与主站的0x1F84对象中保存的内容一致，是则请求访问从站的0x1018对象，否则结束启动并伴随一个错误标识C。在从站再次回复时，判断再次回复的内容是否与主站的0x1F85-0x1F88对象保存的内容一致，是则进行步骤S31，否则结束启动并伴随错误标识D、M、N、O。在从站未回复时，结束启动并伴随一个错误标识B。其中，0x1000对象、0x1018对象用于存储从站的各项信息。

具体地，从站的各项信息包括设备类型信息、厂家标识信息、产品编码信息、版本号信息、序列号信息；0x1000对象对应设备类型信息，0x1018对象四个子项对应厂家标识信息、产品编码信息、版本号信息、序列号信息。

在步骤33中，判断从站是否需要被检查：在从站需被检查时，检查和更新从站的软件程序版本，并判断从站的版本是否已更新，是则执行步骤S50，否则结束启动并伴随错误标识G、H、I。

配置心跳消费者的方法为：获取从站的心跳参数，根据从站的心跳参数设置主站的心跳参数。

检查活跃节点的状态的方法包括：步骤S321：判断心跳消费者的心跳时间是否大于零。在心跳时间大于零时，执行步骤S322：判断主站是否接收到心跳，是则结束检查状态，否则判断未接收到心跳的时间间隔是否超过一个预设时间一。在超时时间超过预设时间一时，结束检查状态并伴随一错误标识E。在接收到心跳的时间间隔未超过预设时间一时，执行步骤S322。在心跳时间等于零时，请求节点监护响应。步骤S323：判断主站是否接收到节点监护回复，是则结束检查状态，否则判断是否超时一个预设时间二，是则结束检查状态并伴随一错误标识F。

错误控制服务的控制方法包括：步骤S401：判断心跳消费者的心跳时间是否大于零。在心跳时间大于零时，执行步骤S402：判断主站是否接收到心跳。在主站接收到心跳时，判定从站启动成功。在主站未接收到心跳时，执行步骤S403：判断未接收到心跳的时间间隔是否超过一个预设时间三，是则伴随错误标识K，否则执行步骤S402。在心跳时间参数等于零时，判断节点是否在网络列表中，是则判断监护时间是否大于零，否则判定从站启动成功。在监护时间大于零时，先启动节点监护，若有回复则判定从站启动成功；在监护时间等于零时，直接判定从站启动成功。

进一步地，为了提高从站启动的完善性，判断从站的配置是否正确的方法包括：步骤S501：判断期望配置的日期及时间是否不为零。在期望配置的日期及时间不为零时，请求访问0x1020对象，并判断响应是否等于期望值。在期望配置的日期及时间为零时，执行步骤S502：更新配置。在响应等于期望值时，结束配置并判定从站的配置正确；在响应不等于期望值时，执行步骤S502。步骤S503：判断配置是否更新成功，是则结束配置并判定从站的配置正确，否则结束启动并伴随一个错位标识J。

这里需要说明的是，在本实施例中，错误标识A-O均为方便表示而进行的设置，在其他实施例中，错误标识还可以采用其他方式表达，并不局限于本实施例中的表达方式。

实施例2

本实施例提供了一种统筹管理器，其用于管理CAN总线上的多个设备中设置的多个模块。所述统筹管理器管理多个模块时，实现实施例1中的CANopen主站的启动方法的步骤。

实施例3

请参阅图4、图5以及图6，本实施例提供了一种统筹管理器，其运行实施例1中的CANopen主站的启动方法的步骤。

为了实现设备的模块化以及可配置化，需要对不同功能进行模块化处理，模块化处理包括单个模块的单文件化以及可配置化。在接下的描述中，用CopMgr表示统筹管理器，并统筹管理所有的模块。

在最底层是通讯对象表(COB)，主要与底层CAN驱动相关的上层结构。

在COB之上是各个模块，PDO是数据同步模块，负责数据同步的。

SDOS、SDOC分别是服务通信对象服务端和客户端，主要是用来传输SDO报文远程读写对象字典的，PDO进行数据传输的处理数据对象模块，而SDO用于远程参数设置的服务数据对象模块，且在需要设置的时候才会进行数据传输。

NMT、NMTM、NMTS主要负责处理两个部分，一个是生命周期监护相关的，另外一个是启动时候的设备事件。

HBP、HBC负责处理心跳机制，EMCP、EMCC负责处理紧急事件。

在这之上的SRD、SDOM是负责动态服务请求，并建立在SDOS、SDOC基础上，AutoHb是自动配置心跳和生命周期的模块。CfgMa是配置管理器，可以利用设备描述文件来配置从站的功能。

统筹管理器管理所有模块并且实现启动和可靠性控制。

上述启动是对所有从站的启动、配置和在此过程中的可能发生的错误处理，可靠性控制是启动后在运行态中的对潜在的错误进行处理。主站启动包括主站端自己的启动和主站并行处理各个从站的启动，主站启动需要等待所有从站启动成功，或不成功进行相应处理。

请参阅图7，为了实现主站的启动流程，在CopMgr里，CopMgr定义了设备的多个状态和事件，事件用来与其他模块进行同步，而状态则用来进行不同形势的不同处理。CopMgr是处于更上层的一个模块，会利用到其他所有模块，CopMgr轮询其他所有模块的process处理，并且维护自己的一个状态机，如图8以及图9所示。其中：

a)设备启动的时候会有一个启动事件，CopMgr会跳到启动状态，在启动状态下检查自己是配置成主站还是从站，这里作为主站是被配置成主站的，然后注册一个SDO动态请求，把自己的SRD注册到SDOM上，SDOM也在主站上，SDO的动态服务请求的注册经历多个步骤。

当经历了动态服务请求注册成功后，SRD注册成功事件会被激活，然后跳到配置状态，并且激活配置事件，每个状态下可能有多个事件，每个事件的激活又分别执行不同的功能。

b)在配置状态下的配置事件中，设置从站的启动初始信息，后激活发送复位事件，继而在发送复位事件中远程复位所有从站，远程复位是通过发送CAN报文实现的，利用NMTM模块对应的COB实现发送，而NMTS有对应的COB实现接收，并锁定对应的回调处理接收事件，这里是复位事件，从站会进行复位操作。

复位从站的一次报文发送中的COB ID如果为0，所有从站都会响应，但是对于接收的从站来说是否执行复位操作取决于发动的报文的数据段的节点ID号，如果节点ID号为0，则所有从站都会执行响应命令，响应的命令取决于主站发送报文的数据段的命令类型。这里是复位命令，如果从站接收的报文中的数据段的节点ID(不是COB ID，COB ID在数据段的前面的CAN标识字段里)不为0，则从站会判断该节点ID是否与自己的ID号一致，如果一致才做出响应，否则不再继续响应。

c)复位所有从站后，首先，主站激活从站节点队列的轮询，这部分主要实现所有从站的启动，这些从站的启动从宽泛的时间概念上来说是并行启动，微观上来说是每个从站挨个执行第一步状态，再挨个执行第二个状态，依次类推，一个记录变量记录已经有多少个从站完成启动过程，等所有从站都完成了启动过程之后，这个记录变量递减为0。之后，判断是否有从站被配置成强制启动类型的，强制启动类型意思是该从站必须启动成功，一个从站完成了启动过程不代表该从站启动成功，可能启动过程中出现错误。被设置强制启动的从站可能因为特殊的任务进而要求必须启动成功，而那些不是很特殊的从站即使启动失败了，也不会影响整个应用的话一般不会被设置成强制启动类型，如果从站有强制启动类型的，则检查该类型的从站必须启动成功，否则主站中止启动，进入中止状态，禁止从站节点队列的轮询。如果强制启动的从站都启动成功了，其他站也都完成了启动过程，主站根据配置是进入等待应用状态还是直接进入运行态，这里被配置成进入等待应用状态。不管是等待应用状态还是进入中止状态，在这之前都会通过回调通知应用程序。这里启动成功后把启动成功的事件通知应用，应用会激活运行事件。

d)在等待应用状态下，由于应用激活了运行事件，所以主站会根据配置决定从站是自己进入运行态还是允许主站通过远程命令让从站进入运行态。这里被配置成主站发送NMTM报文通知从站进入运行态，并且主站自己也进入运行态，至此完成了主站启动和所有从站的启动。

请参阅图10，在一些实施例中，CopMgr还管理从站的启动。

a)在主站启动的时候，需要启动所有从站，启动从站是指对单个从站的启动，并行处理从站启动是对多个从站的并行启动，启动意味着与从站的多次通信交互，启动从站代表了这个过程。

b)启动从站不代表从站启动成功，如果从站没有回复，则检查该从站是否是强制启动以及是否超时。如果是强制启动的并且超时了，那么就通知应用，结束该子站的启动，且发送一个信号2给开始处理从站启动的主流程，如果该从站有回复就检查从站是否启动成功了，没有则通知应用且结束该从站的启动。

c)当启动从站的时候，如果从站没有回复，就会发送远程复位该从站的命令，接着等待1秒重新进入启动该从站流程，如果该从站是强制启动类型的，还需检查在有限的时间内能有回复，如果超时就不会无休止的进行复位该从站然后等待这样的操作了。

d)开始处理从站的启动，这个过程属于主站启动过程中的一部分，在主站启动过程中，需要等待所有从站的启动完毕，这个等待就是附图中描绘的信号，信号1表示所有从站都经历了一次启动。不管这种启动是失败的还是超时的，都会属于一次启动完成，而信号2表示从站中的强制启动类型的从站启动成功对应的信号。该信号表示所有强制启动类型的从站都启动成功了，主站启动的时候需要等待这两个信号。实际上，这两个信号在设计里用两个相关变量来实现其作用，具体为变量1代表所有从站数目，变量2代表强制启动类型的从站数目。当每个从站经历一次启动过程，变量1会减1，而当每个强制启动类型的从站启动成功了，变量2减1。如果所有从站都经历了一次启动流程，那么变量1就会最终等于0，而所有强制启动类型的从站启动成功了，变量2最后也会等于0。主站启动的等待就根据这两个变量做出判断是否所有从站都启动了以及是否强制启动类型的所有从站都启动成功了，进而决定是进入中止启动状态还是进入等待应用状态。

所以信号1在每个从站启动过程结束就会进行减1，而信号2必须等待每个强制启动类型的从站启动成功才减1。

e)等所有从站启动流程结束会结束开始从站的启动，接下来要详细描述单个从站的启动过程。

从站启动流程为：

1)启动一个从站的时候，先检查该从站是否包含在网络列表里，一个主站管理的所有从站的节点号在事先都会被设置了，是通过上位机的配置来配置整个网络的，所有从站的节点号被保存在主站的网络列表里，这个列表就是对象0x1F81的位0位置，对象0x1F81是个数组，数组的每一项对应一个从站，保存了该从站的相关配置，如果它的位0被设置了，表示该数组项对应的从站在网络列表里。

如果该从站的节点号在网络列表里，就会继续启动，否则会结束该从站的启动，结束的意思是进入启动过程步骤的最后一步，检查启动的结果。

2)当从站被主站通过远程报文复位后，从站进行了初步自启动，启动分很多步骤，每个步骤对应一个状态，当进入准运行状态的时候，从站发给主站一个启动通知报文，主站接收到之后判断是否允许启动从站，也就是0x1F81的位2,如果是则开始与从站进行通信交互了。

从站的启动在没有进入运行态的时候是不会执行数据同步的，必须等从站启动成功后进入运行态才会执行数据同步。

如果不允许启动从站则进入到错误控制里处理，错误控制在后面会继续描述，暂时保留。

3)如果允许启动从站，接着请求从站的0x1000对象，请求该对象的过程是一个动态SDO请求的过程，涉及SDO的动态连接请求，主站的SRD进入等待默认连接状态，SDOM扫描分配COB ID给从站的SDOS和主站的SDOC，因为这里请求的是默认连接，默认连接采用的是固定分配的COB ID，而不是动态分配的，当发现请求的是默认连接的时候，会释放分配的COB ID，并且不会去设置从站的SDOS了，因为从站的默认SDOS是固定设置的，在从站SDOS模块初始化的时候被设置了第一个SDOS表项，对应的COB表项都被固定设置了，这个COB ID是与从站节点号相关的，默认连接请求的是固定的SDO通道，当动态SDO连接请求成功之后，会进行一次SDO传输去读取从站的0x1000对象.

4)如果从站没有回复就结束启动，如果有回复，检查回复的内容与主站端0x1F84对象保存的是否一致。如果0x1F84对象数组对应该从站的元素不为0的话，如果不一致则结束启动并伴随错误标识，也就是每一步如果发生错误都会记录下错误类型，等待最后的错误控制处理。如果0x1F84对象为0或者一致的话，接着请求从站的0x1018对象。

5)0x1018对象有四个子索引，包含四个对象，分别请求，并且请求之后等待是否有回复，如果有回复且主站端的0x1F85-0x1F88不为0则检查是否一致，一致则继续下面的流程，不一致则结束启动并记录原因标识。

实际上对象0x1000和对象0x1018一共对应五个参数，分别为从站的设备类型、厂家标识、产品编码、版本号、序列号，通过SDO远程访问对象0x1000和对象0x1018就是为了检查从站的这五个参数与主站端0x1F84-0x1F88对象数组里对应从站的元素是否一致。

6)进入B是可选流程，而C是正常流程，可选流程意思为这部分功能是可以跳过或者保留，但是最终还是进入到C的流程，这在下面继续描述。

7)在可选流程中，检查从站的活跃标志是否被设置了，如果设置了表示是活跃类型从站，则自动配置心跳，自动配置心跳并不是设置从站的心跳参数，而是获取从站的心跳参数去设置主站本地的保存的该从站的心跳参数。也就是进行一次自动配置心跳消费者，所谓心跳消费者是指接收心跳包的站点，各个从站将自己的心跳包发给主站，主站是心跳包的接收者，这个接收者就是心跳消费者HBC(heartbeat consumer)，而产生心跳包的从站是心跳生产者HBP(heartbeat producer)。

8)检查节点状态，等待节点状态的回复，如果节点状态没有接收到则结束启动，如果节点状态接收到了，检查节点当前是否正处于运行态。如果是就进行错误控制处理，走进D流程，后面有描述，如果不是处于运行态，则复位该节点通信。

这么做的意义在于在一个网络中，挂接了多个设备，其中有主站和从站，在第一次启动中主站和从站都启动完毕，之后在运行过程中，可能某些从站出现错误报告给主站，主站需要重新复位从站重新启动所有从站，也可能主站自己因为某些原因需要重启协议栈，但是有些时候可能希望某些从站在其他从站出现故障或者主站需要重启的时候，主站启动的时候不要再重新复位该从站，也许该从站有这特殊的任务需要一直运行，对于这样的从站会被配置成活跃类型的从站，主站启动时候不会再次复位它。

所以活跃类型从站在主站启动的时候并没有被复位，但是活跃类型的从站必须要进入运行态，而要进入运行态，必须要主站发送命令让其进入运行态，而这之前需要复位活跃类型的从站，因为活跃类型的从站必须第一次被主站复位并被主站启动后进入运行态之后才不准主站再次对其进行复位，由于主站刚重启是不知道活跃类型从站是第一次复位还是上次已经被复位了并且进入了运行态，所以主站启动的时候并不复位活跃类型的从站，但是在启动从站的时候开始检查活跃类型的从站的状态，如果活跃类型从站的状态不处于运行态，则表示这是第一次需要被复位然后进入从站启动流程，所以对于活跃类型的从站需要检查节点状态，并判断是否处于运行态，是则直接进入D流程进行错误控制，不是则表示该活跃从站是第一次需要被复位，所以会复位该活跃类型从站。

对于非活跃类型从站则直接进入下面流程，因为非活跃类型的从站在主站启动的期间已经被远程复位过了。

9)查看是否需要检查从站程序版本，需要则检查和更新，更新后再次检查，一致后进入下一个流程，如果不需要检查程序版本也直接进入下一个流程C。

10)检查配置，如果正确就进行错误控制服务，检查配置在接下来有描述。

11)开始错误控制服务。

12)从E过来的流程是不允许启动从站，所以直接结束了并伴随启动成功标识。

而从D过来的流程是活跃类型的从站正在处于运行态，所以不允许被主站再次复位和启动，所以直接结束并伴随一个标识L表示活跃从站已经处于运行态了。

13)之后判断是否要设备进入运行状态，一旦从站进入运行态，数据同步就会被启动，网络节点之间的数据就会实现同步过程了，主站里的与从站相关的输入数据保持一致，而主站的输出数据也会与从站的输出保持一致。

在从站的启动的末尾正是主站启动的末尾实现的功能。

请参阅图11，检查配置属于从站启动中的一部分，主要为检查主站的两个对象是否为0，是0则更新从站的配置(这是第一次配置的)，否则请求从站的0x1020对象，从站的0x1020对象保存了从站配置的最后一次更新的日期和时间，如果从站的配置更新日期和时间与主站端的对应该从站的配置日期和时间一致，那么就不需要被配置了，否则更新配置，更新配置是主站配置从站的某些参数。

请参阅图12，检查节点状态是针对活跃类型的从站而言的，首先查看消费者心跳时间参数是否是非零值。

为了更好的表述这个流程，首先需要明白有两种方法可以获取从站的状态，一种称为心跳的机制，这部分实现的模块分别是HBC模块和HBP模块，HBC模块是心跳的接收者，而HBP模块是心跳的发送者，接收者是消费者，而产生者称作生产者，也就是消费-生产模型，主站是心跳的消费者也就是接收者，而从站是心跳的生产者，从站每隔一段时间发送一次CAN报文给主站，准确的说从站对应HBP模块，而主站对应HBC模块，HBP模块的COB和HBC模块的COB对应起来，一个HBC模块接收多个HBP的心跳包(一个CAN报文，只不过它的COB ID决定它是什么)，准确的说主站包含HBC模块，也就是包含一个HBC表，而HBC表则有多个子项。从站只有一个COB，而且这个COB是与NMTS的COB重合的，这样主站的HBC模块保存了所有从站对应HBP模块的接收者HBC，而一个从站只有一个HBP模块，所以HBP模块发送的报文只有HBC表能响应，因为HBP模块和HBC表的COB ID是与节点相关的，HBP模块和HBC表有CAN标识的对应关系，从站根据心跳时间参数的设定间隔发送心跳包给HBC模块，这个心跳包包含了从站的当前状态，从站是主动发送的，而主站是被动接收的，这就是心跳机制。可见心跳机制用一句话来概括就是从站根据自己的心跳参数决定间隔多久一次发送给主站一个心跳包，心跳包包含了从站的当前状态，所以检查节点的状态，只需要得到从站的一个心跳包就可以知道该从站的状态了。

另外一种获取从站状态的机制叫做节点监护，它是主站主动发送一个节点监护请求，然后从站被动的回复一个报文，这个节点的回复报文中包含了从站当前的状态。

所以检查节点状态的时候，先看消费者心跳时间是否为0，消费者心跳时间是主站端保存的对应从站的心跳参数，但是与该从站的心跳参数的值不一样，前者比后者大，前者是用来检查在规定的时间内是否能够接收到该从站的心跳包，而后者是从站根据这个时间来发送心跳包，所以前者要大于后者，当消费者心跳时间是0的时候，消费者是指主站，也就是主站端保存的从站的应该能在该参数时间内接收到从站的心跳的时间是0，表示从站没有启动心跳机制，而是采用了节点监护机制，那么主站则请求一个节点监护请求，等待从站回复，如果没超时接收到了回复，也就获取了从站的状态，之后结束检查。

如果消费者心跳参数非零，表示采用心跳机制，心跳机制是主站被动从站主动，所以只需要等待心跳包即可，只要接收到心跳包了则结束检查，相反超过了消费者保存的心跳时间也就是超时了，结束检查并伴随一个错误标识记录该错误。

请参阅图13，开始错误控制服务属于从站启动中的一部分，前面的检查活跃类型从站的时候也用到心跳和节点监护机制了，实际上对于普通类型的从站此时已经启动了心跳或节点监护机制了，因为前面的检查配置的时候已经配置了从站，一旦配置了从站的心跳参数，从站就被激活了心跳机制。

这部分主要来检测从站是否被配置成功了，如果被配置成功，心跳包或者生命周期机制已经被激活，要么能接收到心跳包否则发送生命周期监护报文且能在设置的参数时间间隔内能得到回复确认，否则从站并未启动成功。

前面流程的实现建立在事件和状态机的机制之上，状态则是流程的步骤，而事件则决定多个不同的情形处理。

从站启动实现方法主要包含以下几个步骤：

步骤1.检查设备类型、厂家标识、产品编码、版本号、序列号；

步骤2.自动配置心跳消费者(只有活跃类型的才执行)；

步骤3.检查活跃节点的状态(只有活跃类型的才执行)；

步骤4.启动该节点的配置管理；

步骤5.自动配置心跳和生命周期(指生产者)；

步骤6.启动从站节点生命周期；

步骤7.停止从站节点生命周期；

步骤8.启动错误控制；

步骤9.结束后的错误处理。

请参阅图14，在步骤1中：在初始状态下，从站处于空闲状态，当等待启动事件在主站状态机控制的过程中被激活后，从站进入等待启动状态。如果在该状态下没有额外的事件被激活，那么等待一段时间后进入请求设备型号状态。当一开始进入某个状态的时候，也就是发生了状态的改变，触发事件会被激活，发动一次SDO请求，请求从站的设备型号。当从站回复后，在消息的回调中激活SDO传输成功事件，检查请求的结果与主站端的配置是否一致。如果主站端的配置非零的话，若不一致则跳到结束状态，同时记录了错误原因，若一致则跳到请求厂家标识状态，请求从站的厂家标识，按照先前的状态跳转执行检查。

因此，一次检查从站的设备类型、厂家标识、产品编码、版本号、序列号，并与主站保存的配置作比较，如果一致会继续下一个检查，如果当中出现了任何一个不一致则都结束并记录错误原因。

请参阅图15，在步骤3中：当检查完从站的设备类型、厂家标识、产品编码、版本号、序列号后，如果都正确或者主站的保存的参数为0表示无需检查，则都会跳到自动配置心跳消费者状态。

由于发生状态改变，所以触发事件被激活，自动配置心跳消费者和检查状态是为了处理活跃类型的从站。活跃类型的从站如果处于运行态是不允许主站对其复位的，主站在初始化的时候并没有复位和启动该类型的从站。如果存在这样的已经处于运行态的活跃类型的从站，主站启动后要配置主站端的心跳消费者参数，该参数是主站判断从站的心跳报文是否超时的一种量度。由于主站复位了，而主站作为消费者需要重新设置该参数，当触发事件被激活之后，如果是非活跃类型的从站或者该从站虽是活跃类型但是刚刚被复位这两种情况下则不需要配置心跳消费者和检查从站状态，如果是活跃类型从站且未被复位，则激活AutoHb模块的配置心跳消费者事件。

AutoHb模块的配置心跳消费者事件被激活后，会引发自动配置心跳消费者。

当配置成功后AutoHb模块会激活SDO成功事件，会跳到检查状态。

在检查状态下，同样进行了活跃类型的检查以及是否刚复位，所以只处理活跃类型的从站且该从站并没有被复位过，在此状态下等待一个该从站的心跳包，如果等到了心跳包，则一个心跳接收事件被激活，此时主站可以从心跳包中获取该从站的状态，如果该活跃类型的从站处于运行态则跳到错误控制状态，否则复位该从站并进入等待启动状态，重新对该从站执行一次启动流程。

如果没有接收到心跳，主站查看心跳消费者是否已经被设置了，如果被设置了而又发生了迟迟未接收到该从站的心跳包则跳到结束状态，结束该从站的启动流程并记录错误原因。

如果心跳消费者未被设置，则主站通过节点监护机制获取从站状态，主站主动发一个节点监护报文，收到从站回复后获取从站状态，若该从站处于运行态则跳到错误控制状态，反之复位和对该从站重新启动一次启动流程，如果从站没有回复会结束启动过程并记录错误标识。

请参阅图16，不管是活跃类型还是非活跃类型从站，之后都会跳到配置管理器状态，在触发事件下的配置节点事件是应用主动发起的配置任务，不属于启动过程中的环节，因此属于额外任务，该额外任务会启动配置管理器配置节点，配置管理器的部分属于CfgMa模块，该模块会根据设备文件里的内容去配置从站的对象字典，如果配置成功则会跳到结束状态，因为不属于启动流程所以直接结束，如果没有配置文件，则会跳到自动配置心跳和生命周期状态。

这里的配置数据或配置文件是指设备描述文件，设备描述文件里包含了需要配置的对象字典的信息，比如索引子索引和数据等信息，根据这些信息可以配置从站对应的对象，配置过程是通过遍历该文件，通过SDO传输实现的。

如果不是额外的任务而属于启动流程的一部分，在触发事件下应属于配置管理器状态，与前面区别在于如果配置成功会跳到错误控制状态继续启动流程，如果没有配置数据同样也会跳到自动配置心跳和生命周期状态。

也就是如果通过配置管理器配置成功了，直接跳到错误控制状态，不需要再配置心跳和生命周期相关对象了。

如果失败了需要通过另外一种方式去配置心跳和生命周期相关的对象，所以会跳到自动配置心跳和生命周期状态。在该状态下的触发事件下，会激活AutoHb模块的自动配置事件。

该事件会引发AutoHb模块自动配置心跳和生命周期。如果配置成功AutoHb模块会激活SDO成功事件，如果属于额外任务就跳到结束状态，反之属于启动过程则跳到错误控制状态继续进行下一步的启动流程。

启动或停止生命周期属于额外任务，这任务和AutoHb模块相关的，作用在于是选择心跳机制还是生命周期监护机制对从站的错误进行控制。

请参阅图17，在步骤9中，在错误控制状态，主要作用是检查从站是否处于死连接。为了防止从站假连接，有两种机制，一种是心跳机制，从站每隔一段时间发心跳包给主站。这里存在两个间隔，一个是从站根据从站的心跳参数表示的时间发心跳包，这属于心跳生产者的心跳时间参数。另外一个是主站端保存的各个从站的心跳时间参数，这个参数是主站判断从站的心跳包是否超时的参数，处于主站端的心跳参数属于心跳消费者参数。心跳消费者参数大于心跳生产者的时间参数，因为报文的接收和处理需要时间，存在一定的延迟。

在错误控制状态如果接收到了心跳包(心跳接收事件在心跳包接收到的回调中被激活)，表示连接正常，跳到结束状态。如果没有接收到心跳包，查看心跳消费者参数，如果是零表示没有采用心跳机制，而是采用生命监护机制，此时主站配置NMTM表项，NMTM轮询所有表项，发送生命监护报文给该从站，从站回复生命监护报文，可能一次消息超时或长期超时(这种情况为无回复情况)会引发错误处理，错误处理与这里的错误控制不同，错误处理是一个回调，在错误处理中复位从站并跳到等待启动状态。

在结束状态，释放动态SDO连接，跳到空闲状态，并对从站在启动过程中的提前结束启动过程的错误标识进行处理，如果从站无回复则复位并跳到等待启动状态，如果从站启动正确，则远程发报文让该从站进入运行状态，一旦从站进入运行态。PDO数据同步就开始了，如果是其他错误，则管理器进入中止状态。

请参阅图18，接下来介绍AutoHb模块。

AutoHb模块主要实现配置过程的多次SDO传输控制，AutoHb模块主要为从站启动过程中的心跳或生命周期配置服务的。

AutoHb一开始处于空闲状态，激活一个AutoHb的事件，引发一次状态跳转，主要分为四种事件：

a)配置心跳消费者事件

在从站启动过程中，如果从站属于活跃类型，会执行配置心跳消费者，当激活了该事件，跳到请求心跳状态，引发一次SDO传输，跳到等待请求心跳状态，如果请求成功，若心跳生产者心跳值是零，则回到空闲状态，否则获取心跳消费者心跳参数，若心跳消费者不为零比较大小并通知应用，若是零则设置心跳消费者对应该站的心跳值。

也就是如果有必要就配置心跳消费者，如果心跳生产者不为零的话且心跳消费者为零的情况才是必要的。

b)自动配置事件

在自动配置心跳和生命周期状态时会激活该事件，跳到请求心跳状态并进行一次SDO传输。跳到等待请求心跳状态，若心跳生产者参数为零则跳到请求监护周期状态，SDO传输后在等待请求生命周期状态下，若从站生命周期非零则结束，否则需要继续配置，检查心跳消费者心跳参数和本地生命周期参数，若心跳消费者参数非零或本地生命周期为零，且此刻心跳生产者心跳参数为零，则跳到设置心跳状态，反之跳到设置生命周期状态。

自动配置心跳和生命周期只允许配置其中一个，其中一个是配置心跳，另一个是配置生命周期。

对于心跳来说存在生产者与消费者。

生产者即是从站，而消费者是主站。主站端存在心跳参数和生命周期参数，从站也存在心跳参数和生命周期参数。当自动配置的时候，如果从站的心跳非零表示从站已经被配置成心跳机制了不需要再配置了。

如果从站心跳为零即从站心跳没有被配置，检查从站的生命周期是否被配置了。如果从站的生命周期非零表示被配置了，那么也结束自动配置过程，因为这表示从站采用的是生命周期机制。

当从站的心跳和生命周期同时为零的时候，也就是从站没有选择哪种检测死连接的方式，此时需要主站去配置了，选择哪种方式根据主站端的心跳和生命周期参数来决定。

此时主站端的参数存在四种情况：

心跳为零且生命周期为零；

心跳非零且生命周期为零；

心跳非零且生命周期非零；

心跳为零且生命周期非零。

前三种情况会选择配置从站的心跳，第四种情况配置从站的生命周期。

第一种情况虽然主站的心跳为零(主站的心跳是指主站端保存的对应从站的最大心跳超时时间)，但是会用默认值去设置它。

所以设置心跳则跳到设置心跳状态，设置生命周期则跳到设置生命周期状态。在设置心跳状态，用主站端的对应从站的心跳参数设置从站的心跳，如果主站端的心跳为零则用默认值，设置方式是通过SDO传输形式，之后跳到等待设置心跳状态。

在等待设置心跳状态等待SDO传输过程的结束，激活SDO传输完成事件，跳到空闲状态并通知从站启动状态机，通过激活从站启动状态机的SDO完成事件，至此自动配置结束。

如果前面选择的是设置生命周期，则同样用SDO传输方式设置从站的生命周期和生命周期因子两个参数，生命周期是判断从站某次活连接的监护报文的间隔，如果在该间隔内没有收到回复表示消息丢失，而生命周期因子是指多少次的生命周期内没有报文回复，则表示从站丢失。完成生命周期和生命周期因子设置后通知从站启动状态机并结束。

c)启动生命周期事件

该事件则是设置从站的生命周期和生命周期因子两个参数，前提条件是从站并非处于心跳机制下，也就是从站的心跳参数未被设置，一旦设置了从站的生命周期，则启动了生命周期机制。

d)停止生命周期事件

该事件是应用停止生命周期机制，前提条件是从站处于生命周期机制下，停止生命周期则只要清零从站的生命周期和生命周期因子两个参数即可，清零后从站进入节点监护协议下。

在本实施例中，统筹管理器需进行可靠性控制。可靠性控制主要处理网络通信的从站丢失问题，假如一个从站因为某种原因造成通信中断，主站能够检测到这种错误的发生。该处理机制是通过心跳机制和生命周期机制实现的。

可靠性控制包含从站的启动过程，概括的说从站的启动过程会从心跳机制和生命周期机制中选择一个机制去检测通信连接，如果连接丢失，会产生错误处理，而错误处理根据配置不同选择是停止所有节点还是复位所有节点亦或只是复位单个节点后加入启动流程。

首先对于一个设备的启动包含两个部分，术语启动既包含前面从站启动状态机所描述的启动流程，还包含从站自己本身的内部启动几个阶段，这两个部分是相互的。

请参阅图19，当从站上电的时候，它会连接到网络上去，该连接会执行本地的初始化命令，初始化命令分别引发本地的初始化事件、复位节点事件、准复位通信事件、复位通信事件、复位通信之后事件和进入准运行态事件。每个事件会引发各个协议栈的模块事件执行，对于可靠性控制来说涉及两个模块分别是HBP和NMTS(相对从站而言)。在准复位通信事件中从站采用启动协议，在该协议下从站发一个启动报文给主站表示自己启动了，主站接收到之后开始该从站的启动流程，过程如图20所示。主站接收到从站的启动报文，开始启动处理，如果从站在网络列表中则启动该节点设备，也就是无需等待直接进入请求设备类型状态。

当从站进入本地事件的复位通信之后事件的时候，从站采用节点监护协议，在该协议下等待主站的配置，也就是主站在启动从站过程中的自动配置心跳和生命周期，因为此刻从站并没有选择哪种机制作为可靠性机制。

当从站启动成功后，从站选择了心跳或生命周期的其中一个，此后开始可靠性控制。

可靠性控制包含四个部分：

1、心跳机制

在心跳机制下，从站主动发给主站心跳包，设计了HBP模块和HBC模块。主站包含HBC模块而从站包含HBP模块。

HBC表包含多个表项，每个表项对应一个COB，每个表项负责一个从站的心跳信息。HBP模块没有模块表，只有一个COB，虽然这个COB与NMTS的COB是共用的。HBP模块的轮询处理心跳的发送，它检查前一次发送时间与当前时间的间隔是否大于设定的心跳时间参数，如果大于则发送，而HBC模块的轮询处理轮询HBC表的所有项，检查上一次心跳接收时间与当前时间是否发生超时，如果超时则进入上面的错误处理过程。

2、生命周期机制

在生命周期机制下，主站主动发给从站生命监护报文，从站回复给主站表示连接是活跃的。这部分功能包含在NMT NMTM NMTS模块里。

请参阅图21，NMTM模块包含一个模块表(NMTM表)，每个表项对应一个从站，也就是主站端需要保存各个从站的相关信息，这些信息用来进行COB通信。

请参阅图22，NMTM的每个表项对应一个从站，也就是图中的单一表项结构，该结构又包含生命周期参数和从站的信息，以及用来设置COB的COB参数结构，设置的COB包含发送和接收COB，用来唯一的标识这个报文在主站的哪一个NMTM表项与哪一个从站之间的通信。

从站包含NMTS模块，NMTS模块无模块表但是有一个COB，这个COB是与前面的心跳HBP模块对应的COB是同一个COB，因为CAN ID是共用的，分时使用取决于从站当时所采用的是心跳机制还是生命周期机制。

在NMTM模块轮询中根据NMTM表项的生命监护时间发送生命监护报文给从站，而从站的NMTS模块的接收回调中回复报文给主站，NMTM模块轮询若发现从站回复超时则进入错误处理中。

2、启动链和错误处理

在从站启动状态机中的从站启动是对单一从站的启动，实际上是主站管理多个从站一起启动，每个从站的启动快慢是不受控制的，另外有些从站可能启动成功，也有些可能启动失败。

为了处理多个从站的并行启动以及对错误从站的再启动设计了一种启动链来控制，多个从站一开始按照节点顺序启动，之后启动快慢就不受控制了，有可能第二个从站先启动成功，也可能最后一个从站最先启动成功。

启动链方式如下：

a)按节点顺序排列了所有的从站，如果有从站启动成功，启动成功的从站从链中移除，具体为后面启动的从站检查前面是否存在启动成功的。若存在启动成功的则将自己向前移，后续的从站依次进行这种操作，也就是某个或某几个从站启动成功后，后面的从站挨个前移把启动成功的从站挤掉，这相当于启动成功的从站被从链中移除了。

b)启动失败的从站如果不需要再次启动了，和启动成功的从站一样也是从链中被移除。

c)启动失败的从站如果需要再次启动，则失败的从站被移到链尾，实际上是在链尾加一个该从站的拷贝，同时将原份当做需要移除的节点，在链的轮询结束的时候按照类似启动成功或失败的从站一样从链中剔除，这等于将失败的从站直接移到链尾了。

所以当从站在启动过程中失败的话会重新复位并再次启动一次，启动是让从站处于等待状态，复位不是断电类似的重启，程序并没有重新运行，而只是从站本地事件的改变，复位指复位节点或复位通信，因为主站通过报文发送的复位命令，所以为远程复位命令。

但如果该从站一直启动不成功，并不是一直复位，这取决于配置。如果一直有错的话，这里被配置成管理器从配置状态跳出去之后就不再启动。也就是说在从站的启动过程中，第一次启动失败后会先复位然后进行第二次启动尝试。之后管理器跳出配置态，所以第二次启动如果还是失败，则会再次复位该从站，但是并没有进入再次启动的尝试，而是把该从站从启动链移除了。也就是刚才所说的启动失败了不需要再次启动了的情况下将从站从启动列表中移除，如果需要再次启动则将该节点移到启动链尾。

请参阅图23，当发生错误处理的时候，这可能因为主站迟迟未接受到从站的心跳包或主站的生命周期监护报文多次得不到回复，这种情况下根据该从站类型进行配置性的处理，如果该从站是必须启动成功的类型，也就是该从站代表的分布式任务不允许该模块有短暂错误，那么主站在检测到这类从站错误的时候可能会停止整个网络或复位所有设备，如果该设备允许错误后进行复位，那么在错误处理中就会复位该从站并且将该从站入队，加入到启动链中，因为该从站在一开始的启动过程中启动成功后被从启动链中移除了，现在运行过程中失去连接，那么要重新加入到启动链中。

对于心跳机制来说，一个从站的心跳包丢失，只会产生一次错误处理，不会无休止的产生多次错误处理，除非该从站的心跳包重新恢复了，如果恢复了又产生丢失，则会产生新的错误处理。

对于生命周期机制来说，如果一个从站对生命周期监护报文没有回应，从站丢失，会产生一次错误处理，该从站也不再执行监护报文的检查，因为该从站的生命周期不再使能了，所以也不会继续间隔性的发送生命周期监护报文了。如果想再次使能生命周期监护机制，需要对该从站进行新的一次配置，该配置就需要对其进行重新一次的从站启动过程。

当某一个从站出现错误的时候，如果该从站在网络节点列表里，根据主站的配置决定是停止所有节点还是复位所有节点亦或复位单个节点，这主要针对必须启动成功类型的从站而言的，一般性的从站会单独复位并重新启动，重新启动即是将其加入到启动链中并设置其为等待启动状态。

另外还有EMCP、EMCC两个模块处理协议栈运行过程中出现的内部错误，前面描述的心跳或生命周期是通信连接，而内部错误则会产生紧急事件，这些内部错误主要是COB、PDO、NMT三部分运行过程中产生的：

COB的内部错误是和驱动相关的错误，当找不到CAN控制器驱动或驱动状态有错误的时候引发。NMT的内部错误包含所有模块的事件处理中的错误。PDO的错误是在进行PDO同步、发送PDO包、PDO编码、PDO解码和检查映射对象情况下产生的错误。

这些错误都会引发紧急事件的发送，紧急生产者产生紧急事件之后，紧急消费者接受到事件进行处理，主要通知应用程序让应用决定怎么处理，另外在启动过程中产生的紧急事件也会进入到上述的错误处理过程中。

以上仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种CANopen从站的启动方法，其应用于CAN总线上的多个设备，且其中一个设备为主站，其他设备为从站；其特征在于，

所述启动方法包括：

步骤S10，挨个判断所有从站的节点号是否在网络列表中；

在所述从站的节点号在网络列表中时，执行步骤S20，判断是否允许启动所述从站；

在所述从站的节点号未在网络列表中时，结束启动并伴随一个错误标识A；

在允许启动所述从站时，执行步骤S30，判断所述从站的各项信息是否与所述主站中对应的元素一致；

步骤S31，判断所述从站是否为活跃节点；

在所述从站为活跃节点时，执行步骤S32，先配置心跳消费者，后检查所述活跃节点的状态；配置心跳消费者的方法为：获取所述从站的心跳参数，根据所述从站的心跳参数设置所述主站的心跳参数；检查所述活跃节点的状态的方法包括：步骤S321，判断所述心跳消费者的心跳时间是否大于零；在所述心跳时间非零时，执行步骤S322，判断所述主站是否接收到心跳，是则结束检查状态，否则判断所述心跳消费者的心跳间隔是否超过一个预设时间一；在所述心跳间隔超过所述预设时间一时，结束检查状态并伴随一错误标识E；在所述心跳间隔未超过所述预设时间一时，执行步骤S322；在所述心跳时间等于零时，请求节点监护响应；步骤S323，判断所述主站是否接收到节点监护，是则结束检查状态，否则判断是否超时一个预设时间二，是则结束检查状态并伴随一错误标识F；

在所述活跃节点的状态为非运行状态时，复位所述活跃节点的通讯，并执行步骤S33，更新所述从站的软件程序至一个预设版本的程序；

在所述活跃节点的状态为运行状态时，执行步骤S40；

在所述从站为非活跃节点时，执行步骤S30；

在未允许启动所述从站时，执行步骤S40，开始错误控制服务，判断所述从站是否启动成功，是则结束启动并伴随启动成功标识，否则复位所述从站，使所述从站跳转至等待启动状态；

步骤S50，判断所述从站的配置是否正确，是则执行步骤S40，否则结束启动并伴随一个错误标识K。

2.如权利要求1所述的CANopen从站的启动方法，其特征在于，

判断所述从站的各项信息是否与所述主站中对应的元素一致的方法包括：

请求访问所述从站的0x1000对象，并读取所述0x1000对象；

在所述从站首次回复时，判断首次回复的内容是否与所述主站的0x1F84对象中保存的内容一致，是则请求访问所述从站的0x1018对象，否则结束启动并伴随一个错误标识C；

在所述从站再次回复时，判断再次回复的内容是否与所述主站的0x1F85-0x1F88对象保存的内容一致，是则进行步骤S31，否则结束启动并伴随错误标识D、M、N、O；

在所述从站未回复时，结束启动并伴随一个错误标识B；

其中，所述0x1000对象、所述0x1018对象用于存储所述从站的各项信息。

3.如权利要求2所述的CANopen从站的启动方法，其特征在于，所述从站的各项信息包括设备类型信息、厂家标识信息、产品编码信息、版本号信息、序列号信息；所述0x1000对象对应所述设备类型信息，所述0x1018对象的四个子项分别对应所述厂家标识信息、所述产品编码信息、所述版本号信息、所述序列号信息。

4.如权利要求1所述的CANopen从站的启动方法，其特征在于，

在步骤33中，判断所述从站是否需要被检查；

在所述从站需被检查时，检查和更新所述从站的版本，并判断所述从站的版本是否正确，是则执行步骤S50，否则结束启动并伴随错误标识G、H、I。

5.如权利要求1所述的CANopen从站的启动方法，其特征在于，所述错误控制服务的控制方法包括：

步骤S401，判断心跳消费者的心跳时间是否大于零；

在所述心跳时间大于零时，执行步骤S402，判断所述主站是否接收到心跳；

在所述主站接收到心跳时，判定所述从站启动成功；

在所述主站未接收到心跳时，执行步骤S403，判断所述心跳消费者的心跳间隔是否超过一个预设时间三，是则伴随错误标识K，否则执行步骤S402；

在所述心跳时间等于零时，判断节点是否在网络列表中，是则判断监护时间是否大于零，否则判定所述从站启动成功；

在所述监护时间大于零时，先启动节点监护，若得到回复则判定所述从站启动成功；在所述监护时间等于零时，直接判定所述从站启动成功。

6.如权利要求1所述的CANopen从站的启动方法，其特征在于，

判断所述从站的配置是否正确的方法包括：

步骤S501，判断期望配置的日期及时间是否不为零；

在期望配置的日期及时间不为零时，请求访问0x1020对象，并判断响应是否等于期望值；

在期望配置的日期及时间为零时，执行步骤S502，更新配置；

在所述响应等于期望值时，结束配置并判定所述从站的配置正确；在所述响应不等于期望值时，执行步骤S502；

步骤S503，判断配置是否更新成功，是则结束配置并判定所述从站的配置正确，否则结束启动并伴随一个错位标识J。

7.如权利要求1所述的CANopen从站的启动方法，其特征在于，

所述启动方法还包括：

在判定所述从站启动成功后，执行步骤S60，判断所述从站能否被运行；

在能够运行所述从站时，判断所述从站是否需要被独立运行，是则先使所述从站进入运行状态，后结束启动并伴随标识OK，否则判断所述主站是否处于运行态；

在所述主站处于运行态时，使所述从站进入运行状态；

在所述主站未处于运行态，或不能运行所述从站时，结束启动并伴随标识OK。

8.一种统筹管理器，其用于管理CAN总线上的多个设备中设置的多个模块；其特征在于，所述统筹管理器管理多个模块时，实现如权利要求1-7中任意一项所述的CANopen从站的启动方法的步骤。

Images