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

Abstract

本发明公开了一种CANopen主站的启动方法及其统筹管理器，其应用于CAN总线上的多个设备，且其中一个设备为主站，其他设备为从站。启动方法包括：在所述设备上电后，判断设备是否被配置为NMT主站；在设备未被配置为NMT主站时，判断设备是否允许自己启动，是则设备自动跳到NMT运行状态并进入NMT从站模式，否则直接进入NMT从站模式；在设备被配置为NMT主站时，对主站进行NMT飞行主站处理；在主站进行NMT飞行主站处理丢失主站权利后，进入NMT从站模式；在主站进行NMT飞行主站处理获取到主站权利后，判断主站是否要求LSS服务。本发明实现主站的故障切换，并实现主站对从站的层设置和对从站类型的差异化的可靠性控制，提高了分布式系统的整体可靠性与灵活性。

Description

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

技术领域

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

背景技术

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

一个基于CAN总线的网络中有多个设备，如果这些设备是联合起来共同完成一个任务的，则这样的系统即是分布式任务系统。分布式任务系统将整个任务分散到多个设备中，只有所有的设备正常运作才能保证整个任务的顺利执行，因此对分布式系统的每个设备的可靠性控制是关键。但是在现有技术中，单一的统一处理会降低设备之间连接的灵活性，不利于整个分布式系统任务的顺利运作。

发明内容

针对现有技术问题，本发明提供一种CANopen主站的启动方法及其统筹管理器，以缓解分布式系统中所有设备的正常运作问题，以保证从站和主站都正确可靠运作。

从站正确运作通过主站对从站的启动设置和连接检测以实现，并且根据从站类型不同进行差异化的启动；而在主站没有正确运行时，进行主站仲裁以实现主站切换，如此以提高分布式任务的可靠性和灵活性。

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

所述启动方法包括：

步骤S1，在所述设备上电后，判断所述设备是否被配置为NMT主站；

在所述设备未被配置为NMT主站时，判断所述设备是否允许自己启动，是则设备自动跳到NMT运行状态并进入NMT从站模式，否则直接进入NMT从站模式；

在所述设备被配置为NMT主站时，执行步骤S2，对主站进行NMT飞行主站处理；

在所述主站进行NMT飞行主站处理丢失主站权利后，进入NMT从站模式；

在所述主站进行NMT飞行主站处理获胜主站权利后，执行步骤S3，判断所述主站是否要求LSS服务；

在所述主站要求LSS服务时，执行步骤S4，执行LSS主站处理；

在所述主站未要求LSS服务或者执行完成LSS主站处理后，执行步骤S5，判断是否存在从站的活跃位被设置，是则复位活跃位未被设置的从站，否则复位所有从站；

步骤S6，判断所有强制启动的从站是否已启动成功；

在存在强制启动的从站未启动成功时，中止主站启动；

在所有强制启动的从站均启动成功时，执行步骤S7，判断所述主站是否被配置成自动进入运行态；

在所述主站未配置成自动进入运行态时，等待应用引发所述主站进入运行态；

步骤S8，判断所述主站是否允许远程命令所有节点进入运行态；

在所述主站不允许远程命令所有节点进入运行态时，跳转至正常操作以结束启动；

在所述主站允许远程命令所有节点进入运行态时，执行步骤S9，判断可选从站是否启动成功；

在所有从站启动成功时，先远程命令所有从站进入运行态，后跳转至正常操作以结束启动；

在存在从站未启动成功时，先远程命令启动成功的部分从站进入运行态，后跳转至正常操作以结束启动。

作为上述方案的进一步改进，进行NMT飞行主站处理的方法为：被配置成主站的设备会向仲裁器申请仲裁，优先级高的设备获胜并作为主站，优先级低的设备转变为从站。

作为上述方案的进一步改进，所述LSS服务为层设置服务，且用于设置从站的标志信息；其中，所述标志信息包括设备类型、标识、编码、版本号、序列号。

作为上述方案的进一步改进，通过检查对象字典中的对象0x1F80的位0的数值，判断所述设备是否被配置为NMT主站；

通过检查对象字典中的对象0x1F80的位5的数值，判断是否需进行NMT飞行主站处理；

通过检查对象字典中的对象0x1F84的位4的数值，判断从站的活跃位是否被设置；

通过检查对象字典中的对象0x1F81的位0和位3的数值，判断是否是强制启动类型的从站；

通过检查对象字典中的对象0x1F80的位2的数值，判断所述主站是否允许自动进入运行态；

通过检查对象字典中的对象0x1F80的位1和位3的数值，判断所述主站是否允许远程命令所有节点进入运行态。

本发明还提供一种统筹管理器，其运行上述任意一项所述的CANopen主站的启动方法的步骤。

作为上述方案的进一步改进，所述设备启动时，所述统筹管理器跳转至启动状态；

所述统筹管理器在启动状态下，其先检查其所述设备是否被配置为NMT主站，后注册一个SDO动态请求，将所述设备的SDO请求模块注册到SDO管理器上；

当所述统筹管理器的动态服务请求注册成功后，所述统筹管理器跳转至配置状态，并激活配置事件；

在配置状态下的配置事件中，所述统筹管理器先设置从站的启动初始信息，后激活发送复位事件以远程复位所有从站；

所述统筹管理器在所有从站复位后，激活从站节点队列的轮询；

所述统筹管理器在所有强制启动的从站均启动成功后，所述统筹管理器进入等待应用状态；

所述统筹管理器在等待应用状态下，根据配置使启动成功的从站进入运行态。

进一步地，所述统筹管理器通过在所述CAN总线上发送CAN报文远程复位所有从站；

所述主站包括一个NMTM模块、所述从站包括一个NMTS模块；所述NMTM模块对应一个发送通讯对象表，所述NMTS模块对应与所述NMTM模块的发送通讯对象表对应的一个接收通讯对象表；

所述发送通讯对象表发送所述CAN报文至对应的接收通讯对象表，使对应的从站复位。

再进一步地，在复位其中一个从站的一次CAN报文中，当发送通讯对象表的COB ID为0时，所有从站均响应；

所述从站接收的CAN报文中数据段的节点ID号为0时，所有所述从站都响应，且响应的命令对应所述主站发送的CAN报文中数据段的命令类型；

所述从站接收的CAN报文中数据段的节点ID号不为0时，所述从站判断对应的节点ID是否与其ID号一致，并在一致时响应。

再进一步地，从站节点队列的轮询方法包括：

使每个从站并行执行启动过程，并进行完成启动过程的从站数量的记录，且在所有从站完成启动后，所述记录的变量为0；

判断是否存在从站被配置成强制启动类型，并判断强制启动的从站是否均启动成功。

再进一步地，所述统筹管理器通过所述NMTM模块对应子项的通讯对象表发送CAN报文至所述从站的NMTS模块对应的通讯对象表，使所述从站进入运行态。

本发明的CANopen主站的启动方法及其统筹管理器，可以实现对CAN总线上的多个设备的启动，实现主站的故障切换，并实现主站对从站的层设置和对从站类型的差异化的可靠性控制，提高了分布式系统的整体可靠性与灵活性。

附图说明

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

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

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

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

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

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

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

图8为图3中的统筹管理器启动NMT从站的第一部分的流程图；

图9为图3中的统筹管理器启动NMT从站的第二部分的流程图；

图10为图3中的统筹管理器启动NMT从站的第三部分的流程图；

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

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

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

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

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

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

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

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

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

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

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

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

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

具体实施方式

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

实施例1

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

启动方法包括：

步骤S1，在设备上电后，判断该设备是否被配置为NMT主站。

在设备未被配置为NMT主站时，判断设备是否允许自己启动，是则设备自动跳到NMT运行状态并进入NMT从站模式，否则直接进入NMT从站模式；如果设备被配置成主站，检查是否具有飞行主站处理功能，如果具有则执行主站协商，飞行主站处理是指由多个设备被配置成主站，然后会执行仲裁，优先级高的获胜作为主站，优先级低的会转变为从站。

在设备被配置为NMT主站时，执行步骤S2，对主站进行NMT飞行主站处理；其中，在本实施例中，进行NMT飞行主站处理的方法为：被配置成主站的设备请求执行仲裁，优先级高的设备获胜并作为主站，优先级低的设备转变为从站。

在主站进行NMT飞行主站处理丢失主站权利后，进入NMT从站模式。

在主站进行NMT飞行主站处理获胜主站权利后，执行步骤S3，判断主站是否要求LSS服务。

在主站要求LSS服务时，执行步骤S4，执行LSS主站处理。LSS服务为层设置服务，且用于设置从站的标志信息；其中，标志信息包括设备类型、标识、编码、版本号、序列号。

在主站未要求LSS服务或者执行完成LSS主站处理后，执行步骤S5，判断从站的活跃位是否被设置，是则复位活跃位未被设置的从站，否则复位所有从站；所有从站中有活跃位被设置的，就挨个远程重启活跃位没有被设置的，如果都没有设置，一次性重启所有从站，该配置可能让某些特殊的从站不被主站重启，保证从站的特殊性，这在某些应用中可能有特殊用途，比如某些从设备不希望能被主站在任何时刻的重启，该从站可能要进行某些特殊的任务。

步骤S6，判断所有强制启动的从站是否已启动成功。

在存在强制启动的从站未启动成功时，中止主站启动。

在所有强制启动的从站均启动成功时，执行步骤S7，判断主站是否被配置成自动进入运行态。

在主站未配置成自动进入运行态时，等待应用引发主站进入运行态。

步骤S8，判断主站是否允许远程命令所有节点进入运行态。

在主站未允许远程命令所有节点进入运行态时，跳转至正常操作以结束启动。

在主站允许远程命令所有节点进入运行态时，执行步骤S9，判断可选从站是否启动成功。这里，由于开始所有从站启动之后，并不代表所有从站启动成功了，也有可能有些从站丢失了或发生其他错误，那么该从站是没有启动成功了，有些从站没有启动成功也会继续下去，但是可能有些从站因为负责的任务很重要，必须要启动成功，这些从站会被配置成强制启动的从站，如果有这样的从站存在，这些强制启动的从站必须启动成功，否则进入启动中止状态。

在所有从站启动成功时，先远程命令所有从站均进入运行态，后跳转至正常操作以结束启动。在存在从站未启动成功时，先远程命令启动成功的部分从站进入运行态，后跳转至正常操作以结束启动。

在本实施例中，步骤S1的判断方法具体为：

通过检查对象字典中的对象0x1F80的位0的数值，判断设备是否被配置为NMT主站；设备启动后，该设备是作为主站还是从站是由对象0x1F80的位0决定的，也就是被配置的，而对象0x1F80就是进行这样类似的配置，它还会进行其他多种属性的配置，同样其他很多对象可能作为不同属性的配置。一个对象指向一个判断，都表示一种配置或参数设置。故在步骤S2-S9中：

通过检查对象字典中的对象0x1F80的位1和位3的数值，判断主站是否远程开始所有节点；通过检查对象字典中的对象0x1F80的位2的数值，判断主站是否允许自动进入运行态；通过检查对象字典中的对象0x1F80的位5的数值，判断是否需进行NMT飞行主站处理；通过检查对象字典中的对象0x1F84的位4的数值，判断从站的活跃位是否被设置；通过检查对象字典中的对象0x1F81的位0和位3的数值，判断是否是强制启动类型的从站。

如此，本实施例可以实现对CAN总线上的多个设备的启动，实现主站的故障切换，并实现主站对从站的层设置和对从站类型的差异化的可靠性控制，提高了分布式系统的整体可靠性与灵活性。

实施例2

本实施例提供了一种统筹管理器，其运行实施例1中的CANopen主站的启动方法的步骤。

统筹管理器在启动状态下，其先检查其设备是否被配置为NMT主站，后注册一个SDO动态请求，将设备的SDO请求模块注册到SDO管理器上。当统筹管理器的动态服务请求注册成功后，统筹管理器跳转至配置状态，并激活配置事件。在配置状态下的配置事件中，统筹管理器先设置从站的启动初始信息，后激活发送复位事件以远程复位所有从站。统筹管理器在所有从站复位后，激活从站节点队列的轮询。统筹管理器在所有强制启动的从站均启动成功后，统筹管理器进入等待应用状态。统筹管理器在等待应用状态下，根据配置使启动成功的从站进入运行态。

其中，统筹管理器通过在CAN总线上发送CAN报文而远程复位所有从站。主站设备包括一个NMTM模块，从站包括一个NMTS模块；NMTM模块对应一个发送通讯对象表，NMTS模块对应与NMTM模块的发送通讯对象表对应的一个接收通讯对象表。发送通讯对象表发送CAN报文至对应的接收通讯对象表，使对应的从站复位。

其中，统筹管理器通过NMTM模块对应子项的COB发送CAN报文至从站NMTS模块对应的COB，使从站进入运行态。

基于上述说明，在本实施例中，在复位其中一个从站的一次CAN报文中，当发送通讯对象表的COB ID为0时，所有从站均响应。从站接收的CAN报文中数据段的节点ID号为0时，从站响应，且响应的命令对应主站发送的CAN报文中数据段的命令类型。从站接收的CAN报文中数据段的节点ID号不为0时，从站判断对应的节点ID是否与其ID号一致，并在一致时响应。

从站节点队列的轮询方法包括：

使每个从站并行执行启动过程，并进行完成启动过程的从站数量的记录，且在所有从站完成启动后，记录的变量为0；

判断是否存在从站被配置成强制启动类型，并判断强制启动的从站是否均启动成功。

实施例3

请参阅图3，本实施例提供了一种统筹管理器，其运行实施例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是配置管理器，可以利用设备描述文件来配置从站的功能。

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

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

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

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报文通知从站进入运行态，并且主站自己也进入运行态，至此完成了主站启动和所有从站的启动。

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

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

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

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

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

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

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

请参阅图8，从站启动流程为

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

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

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

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

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

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

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

11)开始错误控制服务。

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

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

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

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

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

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

为了更好的表述这个流程，首先需要明白有两种方法可以获取从站的状态，一种称为心跳的机制，这部分实现的模块分别是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，在步骤7中：不管是活跃类型还是非活跃类型从站，之后都会跳到配置管理器状态，在触发事件下的配置节点事件是应用主动发起的配置任务，不属于启动过程中的环节，因此属于额外任务，该额外任务会启动配置管理器配置节点，配置管理器的部分属于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 (10)

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

所述启动方法包括：

步骤S1，在所述设备上电后，判断所述设备是否被配置为NMT主站；

在所述设备未被配置为NMT主站时，判断所述设备是否允许自己启动，是则设备自动跳到NMT运行状态并进入NMT从站模式，否则直接进入NMT从站模式；

在所述设备被配置为NMT主站时，执行步骤S2，对主站进行NMT飞行主站处理；

在所述主站进行NMT飞行主站处理丢失主站权利后，进入NMT从站模式；

在所述主站进行NMT飞行主站处理获胜主站权利后，执行步骤S3，判断所述主站是否要求LSS服务；

在所述主站要求LSS服务时，执行步骤S4，执行LSS主站处理；

在所述主站未要求LSS服务或者执行完成LSS主站处理后，执行步骤S5，判断是否存在从站的活跃位被设置，是则复位活跃位未被设置的从站，否则复位所有从站；

步骤S6，判断所有强制启动的从站是否已启动成功；

在存在强制启动的从站未启动成功时，中止主站启动；

在所有强制启动的从站均启动成功时，执行步骤S7，判断所述主站是否被配置成自动进入运行态；

在所述主站未配置成自动进入运行态时，等待应用引发所述主站进入运行态；

步骤S8，判断所述主站是否允许远程命令所有节点进入运行态；

在所述主站不允许远程命令所有节点进入运行态时，跳转至正常操作以结束启动；

在所述主站允许远程命令所有节点进入运行态时，执行步骤S9，判断可选从站是否启动成功；

在所有从站启动成功时，先远程命令所有从站进入运行态，后跳转至正常操作以结束启动；

在存在从站未启动成功时，先远程命令启动成功的部分从站进入运行态，后跳转至正常操作以结束启动。

2.如权利要求1所述的CANopen主站的启动方法，其特征在于，进行NMT飞行主站处理的方法为：被配置成主站的设备会向仲裁器申请仲裁，优先级高的设备获胜并作为主站，优先级低的设备转变为从站。

3.如权利要求1所述的CANopen主站的启动方法，其特征在于，所述LSS服务为层设置服务，且用于设置从站的标志信息；其中，所述标志信息包括设备类型、厂家标识、产品编码、版本号、序列号。

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

通过检查对象字典中的对象0x1F80的位0的数值，判断所述设备是否被配置为NMT主站；

通过检查对象字典中的对象0x1F80的位5的数值，判断是否需进行NMT飞行主站处理；

通过检查对象字典中的对象0x1F84的位4的数值，判断从站的活跃位是否被设置；

通过检查对象字典中的对象0x1F81的位0和位3的数值，判断是否是强制启动类型的从站；

通过检查对象字典中的对象0x1F80的位2的数值，判断所述主站是否允许自动进入运行态；

通过检查对象字典中的对象0x1F80的位1和位3的数值，判断所述主站是否允许远程命令所有节点进入运行态。

5.一种统筹管理器，其特征在于，其运行如权利要求1-4中任意一项所述的CANopen主站的启动方法的步骤。

6.如权利要求5所述的统筹管理器，其特征在于，所述设备启动时，所述统筹管理器跳转至启动状态；

所述统筹管理器在启动状态下，其先检查其所述设备是否被配置为NMT主站，后注册一个SDO动态请求，将所述设备的SDO请求模块注册到SDO管理器上；其中，在检查设备配置成主站的情况下，才会注册一个SDO动态请求；

当所述统筹管理器的动态服务请求注册成功后，所述统筹管理器跳转至配置状态，并激活配置事件；

在配置状态下的配置事件中，所述统筹管理器先设置从站的启动初始信息，后激活发送复位事件以远程复位所有从站；

所述统筹管理器在所有从站复位后，激活从站节点队列的轮询；

所述统筹管理器在所有强制启动的从站均启动成功后，所述统筹管理器进入等待应用状态；

所述统筹管理器在等待应用状态下，根据配置使启动成功的从站进入运行态。

7.如权利要求6所述的统筹管理器，其特征在于，所述统筹管理器通过在所述CAN总线上发送CAN报文远程复位所有从站；

所述主站包括一个NMTM模块，所述从站包括一个NMTS模块；所述NMTM模块对应一个发送通讯对象表，所述NMTS模块对应与所述NMTM模块的发送通讯对象表对应的一个接收通讯对象表；

所述发送通讯对象表发送所述CAN报文至对应的接收通讯对象表，使对应的从站复位。

8.如权利要求7所述的统筹管理器，其特征在于，在复位其中一个从站的一次CAN报文中，当发送通讯对象表的COB ID为0时，所有从站均响应；

所述从站接收的CAN报文中数据段的节点ID号为0时，所有所述从站都响应，且响应的命令对应所述主站发送的CAN报文中数据段的命令类型；

所述从站接收的CAN报文中数据段的节点ID号不为0时，所述从站判断对应的节点ID是否与其ID号一致，并在一致时响应。

9.如权利要求6所述的统筹管理器，其特征在于，从站节点队列的轮询方法包括：

使每个从站并行执行启动过程，并进行完成启动过程的从站数量的记录，且在所有从站完成启动后，所述记录的变量为0；

判断是否存在从站被配置成强制启动类型，并判断强制启动的从站是否均启动成功。

10.如权利要求6所述的统筹管理器，其特征在于，所述统筹管理器通过所述NMTM模块对应子项的通讯对象表发送CAN报文至所述从站的NMTS模块对应的通讯对象表，使所述从站进入运行态。

Images