一种基于控制器局域网络的设备管理方法及装置与流程

本申请涉及通信技术领域，尤其涉及一种基于控制器局域网络的设备管理方法及装置。

背景技术：

随着技术的不断发展，终端的设备例如各种传感器越来越多，甚至于未来设备的数量可能会远远超过人类的数量。为了应对如此多的设备连接通信，物联网技术应运而生。

基于CAN(控制器局域网络)方式连接通信的物联网中，为了便于管理接入的设备，CAN主控制器需要给接入的设备分配ID。

现有技术中，由于CAN本身只是一个简单的通用协议框架，并没有分配ID的功能，所以分配ID的工作通常都是人工完成的。然而，人工分配ID往往效率较低，并且人工成本也较高。

技术实现要素：

本申请提供基于控制器局域网络的设备管理方法及装置，用以解决现有技术中人工分配ID效率较低，成本较高的问题。

根据本申请实施例提供的一种基于控制器局域网络的设备管理方法，所述方法包括：

控制器局域网络的设备节点广播DHCP Discover报文；其中，所述DHCP Discover报文中携带一个随机数，所述随机数用作临时标识发送设备地址，所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文；

控制器局域网络的主控制器接收到DHCP Discover报文后根据所述随机数分配一个可用的第一ID，并广播DHCP Offer报文；所述DHCP Offer报文中携带所分配的第一ID；

控制器局域网络的设备节点接收到控制器局域网络的主控制器返回的DHCP Offer报文后，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文；其中，所述DHCP Request报文携带所述第二ID；

控制器局域网络的主控制器接收到DHCP Request报文后判断该报文中的第二ID与之前所分配的第一ID是否一致；

控制器局域网络的主控制器在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，将所述第二ID确定为第三ID，并广播DHCP Ack报文；其中，所述DHCP Ack报文中携带所确定的第三ID；

控制器局域网络的设备节点接收到控制器局域网络的主控制器返回的DHCP Ack报文后，判断该报文中的第三ID与所述第二ID是否一致；

控制器局域网络的设备节点在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID。

可选的，所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

可选的，所述分配的ID位于4到240之间。

根据本申请实施例提供的一种基于控制器局域网络的设备管理方法，所述方法应用在所述控制器局域网络的设备节点，所述方法包括：

广播DHCP Discover报文；其中，所述DHCP Discover报文中携带一个随机数，所述随机数用作临时标识发送设备地址，所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文；

在接收到控制器局域网络的主控制器返回的DHCP Offer报文后，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文；其中，所述DHCP Request报文携带所述第二ID；

在接收到控制器局域网络的主控制器返回的DHCP Ack报文后，判断该报文中的第三ID与所述第二ID是否一致；

在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID。

可选的，在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID之后，所述方法还包括：

将所述最终的ID保存在存储器中；

相应地，

在所述广播DHCP Discover报文之前，所述方法还包括：

判断保存的ID是否有效；

在保存的ID无效的情况下，执行所述广播DHCP Discover报文；

在保存的ID有效的情况下，将所述已存在的ID确定为第二ID，执行所述广播DHCP Request报文。

可选的，所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

根据本申请实施例提供的一种基于控制器局域网络的设备管理方法，所述方法应用在所述控制器局域网络的主控制器，所述方法包括：

接收到控制器局域网络的设备节点广播的DHCP Discover报文后，根据所述随机数分配一个可用的第一ID，并广播DHCP Offer报文；所述DHCP Offer报文中携带所分配的第一ID；

接收到控制器局域网络的设备节点广播的DHCP Request报文后，判断该报文中的第二ID与之前所分配的第一ID是否一致；

在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，将所述第二ID确定为第三ID，并广播DHCP Ack报文；其中，所述DHCP Ack报文中携带所确定的第三ID。

可选的，所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

可选的，所述分配的ID位于4到240之间。

根据本申请实施例提供的一种基于控制器局域网络的设备管理装置，所述装置应用在所述控制器局域网络的设备节点，所述装置包括：

第一广播单元，用于广播DHCP Discover报文；其中，所述DHCP Discover报文中携带一个随机数，所述随机数用作临时标识发送设备地址，所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文；

第二广播单元，用于在接收到控制器局域网络的主控制器返回的DHCP Offer报文后，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文；其中，所述DHCP Request报文携带所述第二ID；

判断单元，用于在接收到控制器局域网络的主控制器返回的DHCP Ack报文后，判断该报文中的第三ID与所述第二ID是否一致；

确定单元，用于在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID。

可选的，在所述确定单元之后，所述装置还包括：

存储子单元，用于将所述最终的ID保存在存储器中；

相应地，

在所述第一广播单元之前，所述装置还包括：

判断子单元，用于判断保存的ID是否有效；

所述第一广播单元，还用于在保存的ID无效的情况下，广播DHCP Discover报文；

所述第二广播单元，还用于在保存的ID有效的情况下，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文。

根据本申请实施例提供的一种基于控制器局域网络的设备管理装置，所述装置应用在所述控制器局域网络的主控制器上，所述装置包括：

分配单元，用于接收到控制器局域网络的设备节点广播的DHCP Discover报文后，根据所述随机数分配一个可用的第一ID；

第三广播单元，用于广播DHCP Offer报文；所述DHCP Offer报文中携带所分配的第一ID；

判断单元，用于接收到控制器局域网络的设备节点广播的DHCP Request报文后，判断该报文中的第二ID与之前所分配的第一ID是否一致；

第四广播单元，在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，将所述第二ID确定为第三ID，并广播DHCP Ack报文；其中，所述DHCP Ack报文中携带所确定的第三ID。

可选的，所述分配的ID位于4到240之间。

本申请实施例，借鉴了DHCP入网报文，在控制器局域网络协议中预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文。如此，控制器局域网络的设备节点与主控制器可以实现DHCP报文交互，即与DHCP入网报文类似的，设备节点可以广播携带随机数的DHCP Discover报文；主控制器可以根据所述随机数分配一个可用的第一ID，并通过DHCP Offer报文广播出去；设备节点接收到DHCP Offer报文后将所述第一ID作为第二ID后，通过DHCP Request报文广播出去；主控制器在所述第二ID与第一ID一致的情况下，将所述第二ID作为第三ID并通过DHCP Ack报文广播出去；最后设备节点在判断所述第三ID与第二ID一致的情况下，将所述第三ID确定为最终的ID。这样，实现了控制器局域网络可以自动地对接入的设备分配ID，实现了提高分配ID的效率，并且由于无需人工分配ID，相应地也降低了运营成本。

附图说明

图1是本申请一实施例提供的基于控制器局域网络的设备管理方法的流程图；

图2是本申请一实施例提供的DHCP Discover报文格式示意图；

图3是本申请一实施例提供的DHCP Offer报文格式示意图；

图4是本申请一实施例提供的DHCP Request报文格式示意图；

图5是本申请一实施例提供的DHCP Ack报文格式示意图；

图6是本申请一实施例提供的DHCP NAck报文格式示意图；

图7是本申请一实施例提供的基于控制器局域网络的设备管理方法的流程图；

图8是本申请一实施例提供的基于控制器局域网络的设备管理方法的流程图；

图9是本申请提供的基于控制器局域网络的设备管理装置所在设备的一种硬件结构图；

图10是本申请一实施例提供的基于控制器局域网络的设备管理装置的模块示意图；

图11是本申请一实施例提供的基于控制器局域网络的设备管理装置的模块示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，控制器局域网络即CAN总线，是一种传统的有线连接方式，用于实现各个设备之间简单的物理连接。基于CAN方式连接通信时，需要对接入的设备分配ID。ID与设备之间是一一对应的关系。通过ID可以快速查找到对应的设备，如此方便管理接入的设备。然而，由于CAN本身并没有分配ID的功能，所以分配ID的工作通常都是人工完成的。然而，人工分配ID往往效率较低，特别是在成套设备接入的情况下，容易出现错误，并且人工成本导致的运营成本也较高。

为了解决上述问题，请参见图1，为本申请一实施例提供的一种基于控制器局域网络的设备管理方法的流程图，该实施例从控制器局域网络的主控制器和设备节点这两侧进行描述，包括以下步骤：

步骤110：控制器局域网络的设备节点广播DHCP Discover报文；其中，所述DHCP Discover报文中携带一个随机数，所述随机数用作临时标识发送设备地址，所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文。

本实施例中，在控制器局域网络协议CAN中，具有一个29bit(位)的扩展ID。

所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文。即，在该扩展ID中重新定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文这五种报文类型。

如下详细介绍所述定义的五种DHCP报文：

如图2所示，为本申请实施例提供的一种DHCP Discover报文格式示意图。图2中，利用原扩展ID的29bit信息，广播DHCP Discover，其中，

第0-4bit用于表示报文的分帧序列；本例子中为1111；

第5bit用于表示报文的最后一帧；本例子中为0；

第6-13bit用于表示报文的源地址；本例子中为11111111；

第14-21bit用于表示报文的目的地址；本例子中为00000001；

第22bit用于表示报文是请求报文还是应答报文，1表示请求报文，0表示应答报文；本例子中为1，即DHCP Discover报文为请求报文；

第23-26bit用于表示报文保留；本例子中为0101；

第27-28bit用于表示优先级；本例子中为00；

Data(数据区)，具有3byte(字节)，用于表示报文类型和随机数。其中，所述随机数占用了2字节，所以报文类型占用了1字节；本例子中为0x01+0x0004，即报文类型为1，随机数为4。

需要说明的是，由于所述报文类型仅占用了1字节，所以数据区定义报文类型时，将1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

需要说明的是，所述随机数为2字节，作为一个临时标识，对应于设备地址，并用于申请ID。

如图3所示，为本申请实施例提供的一种DHCP Offer报文格式示意图。图3中，利用原扩展ID的29bit信息，所述DHCP Offer中，

第0-4bit用于表示报文的分帧序列；本例子中为1111；

第5bit用于表示报文的最后一帧；本例子中为0；

第6-13bit用于表示报文的源地址；本例子中为00000001；

第14-21bit用于表示报文的目的地址；本例子中为11111111；

第22bit用于表示报文是请求报文还是应答报文，1表示请求报文，0表示应答报文；本例子中为0，即DHCP Offer报文为应答报文；

第23-26bit用于表示报文保留；本例子中为0101；

第27-28bit用于表示优先级；本例子中为00；

Data(数据区)，具有4byte(字节)，用于表示报文类型、随机数和第一ID。其中，所述报文类型占用了1字节，所述随机数占用了2字节，所述第一ID占用了1字节。本例子中为0x02+0x0004+0x05,即报文类型为2，随机数为4，第一ID为5。

需要说明的是，由于所述报文类型仅占用了1字节，所以数据区定义报文类型时，将1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

需要说明的是，所述随机数为2字节，在DHCP Offer报文中的随机数与DHCP Discover报文中的随机数为同一个。

如图4所示，为本申请实施例提供的一种DHCP Request报文格式示意图。图4中，利用原扩展ID的29bit信息，广播DHCP Request，其中，

第0-4bit用于表示报文的分帧序列；本例子中为1111；

第5bit用于表示报文的最后一帧；本例子中为0；

第6-13bit用于表示报文的源地址；本例子中为11111111；

第14-21bit用于表示报文的目的地址；本例子中为00000001；

第22bit用于表示报文是请求报文还是应答报文，1表示请求报文，0表示应答报文；本例子中为1，即DHCP Request报文为请求报文；

第23-26bit用于表示报文保留；本例子中为0101；

第27-28bit用于表示优先级；本例子中为00；

Data(数据区)，具有2byte(字节)，用于表示报文类型和第二ID。其中，所述报文类型占用了1字节，所述第二ID占用了1字节。本例子中为0x03+0x05,即报文类型为3，第二ID为5。

需要说明的是，由于所述报文类型仅占用了1字节，所以数据区定义报文类型时，将1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

如图5所示，为本申请实施例提供的一种DHCP Ack报文格式示意图。图5中，利用原扩展ID的29bit信息，所述DHCP Ack中，

第0-4bit用于表示报文的分帧序列；本例子中为1111；

第5bit用于表示报文的最后一帧；本例子中为0；

第6-13bit用于表示报文的源地址；本例子中为00000001；

第14-21bit用于表示报文的目的地址；本例子中为11111111；

第22bit用于表示报文是请求报文还是应答报文，1表示请求报文，0表示应答报文；本例子中为0，即DHCP Ack报文为应答报文；

第23-26bit用于表示报文保留；本例子中为0101；

第27-28bit用于表示优先级；本例子中为00；

Data(数据区)，具有2byte(字节)，用于表示报文类型和第三ID。其中，所述报文类型占用了1字节，所述第三ID占用了1字节。本例子中为0x04+0x05,即报文类型为4，第三ID为5。

需要说明的是，由于所述报文类型仅占用了1字节，所以数据区定义报文类型时，将1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

如图6所示，为本申请实施例提供的一种DHCP NAck报文格式示意图。图6中，利用原扩展ID的29bit信息，所述DHCP NAck中，

第0-4bit用于表示报文的分帧序列；本例子中为1111；

第5bit用于表示报文的最后一帧；本例子中为0；

第6-13bit用于表示报文的源地址；本例子中为00000001；

第14-21bit用于表示报文的目的地址；本例子中为11111111；

第22bit用于表示报文是请求报文还是应答报文，1表示请求报文，0表示应答报文；本例子中为0，即DHCP NAck报文为应答报文；

第23-26bit用于表示报文保留；本例子中为0101；

第27-28bit用于表示优先级；本例子中为00；

Data(数据区)，具有2byte(字节)，用于表示报文类型和第四ID。其中，所述报文类型占用了1字节，所述源地址占用了1字节。本例子中为0x05+0x00,即报文类型为5，第四ID为0。

需要说明的是，由于所述报文类型仅占用了1字节，所以数据区定义报文类型时，将1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。所述第四ID在后面进行说明。

由于上述CAN协议预先定义了DHCP报文，所以控制器局域网络的设备节点可以广播DHCP Discover报文，并且该报文中携带一个随机数。所述随机数用作临时标识发送设备地址。值得一提的是，所述设备地址具有唯一性，即每个设备都具有一个唯一的设备地址。

步骤120：控制器局域网络的主控制器接收到DHCP Discover报文后根据所述随机数分配一个可用的第一ID，并广播DHCP Offer报文；所述DHCP Offer报文中携带所分配的第一ID。

本实施例中，控制器局域网络的主控制器接收到设备节点广播的DHCP Discover报文后，可以根据随机数分配一个可用的ID(第一ID)。

在实际应用中，ID为1字节，其最大范围为0-255；由于定义了特殊功能的ID占用了编号(例如，DHCP NAck报文会携带的ID为0)，所以能留给设备节点使用的ID为4-240之间。

例如，主控制器接收到图2所示的DHCP Discover报文后，可以分配一个5(可用的ID)，并且广播如图3所示的DHCP Offer报文，该DHCP Offer报文的数据区中携带有所分配的ID即5。

步骤130：控制器局域网络的设备节点接收到控制器局域网络的主控制器返回的DHCP Offer报文后，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文；其中，所述DHCP Request报文携带所述第二ID。

本实施例中，控制器局域网络的设备节点接收到主控制器发送的DHCP Offer报文后，可以将该DHCP Offer报文中数据区内的第一ID确定为第二ID，并通过DHCP Request报文广播出去。

例如，设备节点接收到图3所示的DHCP Offer报文后，可以将第一ID(5)确定为第二ID，并广播图4所示的DHCP Request报文，在该DHCP Request报文的数据区内第二ID为5。

值得一提的是，如果控制器局域网络的设备节点没有接收到返回的DHCP Offer报文后，可以重复执行步骤110步骤。

步骤140：控制器局域网络的主控制器接收到DHCP Request报文后判断该报文中的第二ID与之前所分配的第一ID是否一致。

本实施例中，控制器局域网络的主控制器接收到设备节点广播的DHCP Request报文后，需要判断该DHCP Request报文中的第二ID与之前所分配的第一ID是否一致。

如果不一致，说明广播该DHCP Request报文的设备节点不合法，则主控制器可以广播DHCP NAck报文，所述DHCP NAck报文中携带有第四ID。如图6所示，DHCP NAck报文中数据区携带有第四ID，并且所述第四ID不是一个有效的ID，即不位于4-240之间。例如本例子中的第四ID为0。

相对应的，设备节点在接收到所述DHCP报文后，解析该报文得到Data(数据区)的报文类型为NAck的情况下，可以需要重新执行步骤110。例如，接收到图6所示的DHCP报文后，解析DHCP报文得到Data(数据区)的报文类型为5，由于数据区定义报文类型时，将5代表NAck，所以可以确定该DHCP报文为DHCP NAck报文，从而重新执行步骤110。

如果一致，说明广播该DHCP Request报文的设备节点合法，则执行步骤150。

步骤150：控制器局域网络的主控制器在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，将所述第二ID确定为第三ID，并广播DHCP Ack报文；其中，所述DHCP Ack报文中携带所确定的第三ID。

本实施例中，在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，控制器局域网络的主控制器可以将所述第二ID确定为第三ID，并通过DHCP Ack报文将所述第三ID广播出去。

以图3和图4所示的DHCP报文为例，由于图4所示的DHCP Request报文数据区中的第二ID(为5)，与之前所分配的第一ID即图3数据区中的第一ID(为5)是一致的，所以主控制器可以将所述第二ID确定为第三ID，广播如图5所示的DHCP Ack报文，该DHCP Ack报文的数据区中携带有第三ID(为5)。

步骤160：控制器局域网络的设备节点接收到控制器局域网络的主控制器返回的DHCP Ack报文后，判断该报文中的第三ID与所述第二ID是否一致。

本实施例中，控制器局域网络的设备节点接收到主控制器返回的DHCP Ack报文后，需要判断该DHCP Ack报文中的第三ID与所确定的第二ID是否一致。

如果一致，执行步骤170。

如果不一致，则重复执行步骤110。

步骤170：控制器局域网络的设备节点在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID。

本实施例中，在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，控制器局域网络的设备节点最终可以将所述第三ID号确定为最终的ID。

通过本申请实施例，借鉴了DHCP入网报文，在控制器局域网络协议中预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文。如此，控制器局域网络的设备节点与主控制器可以实现DHCP报文交互，即与DHCP入网报文类似的，设备节点可以广播携带随机数的DHCP Discover报文；主控制器可以根据所述随机数分配一个可用的第一ID，并通过DHCP Offer报文广播出去；设备节点接收到DHCP Offer报文后将所述第一ID作为第二ID后，通过DHCP Request报文广播出去；主控制器在所述第二ID与第一ID一致的情况下，将所述第二ID作为第三ID并通过DHCP Ack报文广播出去；最后设备节点在判断所述第三ID与第二ID一致的情况下，将所述第三ID确定为最终的ID。这样，实现了控制器局域网络可以自动地对接入的设备分配ID，实现了提高分配ID的效率，并且由于无需人工分配ID，相应地也降低了运营成本。

以下结合图7介绍本申请以控制器局域网络的设备节点为主体的方法实施例，该实施例可以对应图1：

步骤210：广播DHCP Discover报文；其中，所述DHCP Discover报文中携带一个随机数，所述随机数用作临时标识发送设备地址，所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文。

可选的，所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

步骤220：在接收到控制器局域网络的主控制器返回的DHCP Offer报文后，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文；其中，所述DHCP Request报文携带所述第二ID。

步骤230：在接收到控制器局域网络的主控制器返回的DHCP Ack报文后，判断该报文中的第三ID与所述第二ID是否一致。

步骤240：在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID。

在实际应用过程中，例如传感器这样微型的设备是低功耗的，不会一直上电。在设备重新上电时，会将其视为新接入的设备，然而，该设备其实已经获取了ID，如此就会造成多次申请ID，不仅占用了多个可用ID，而且也对服务器造成额外的压力。

为了解决上述问题，在上述图7基础上，在本申请的另一个实施例中，在所述步骤240之后，所述方法还可以包括：

将所述最终的ID保存在存储器中；

相应地，

在所述步骤210之前，所述方法还包括：

判断保存的ID是否有效；

在保存的ID无效的情况下，执行所述步骤210，即广播DHCP Discover报文；

在保存的ID有效的情况下，将所述存储器中保存的ID确定为第二ID，执行所述广播DHCP Request报文。

本实施例中，所述存储器可以包括例如Flash(Flash EEPROM Memory，闪存)。

设备上电后，通过查询存储器中保存的ID；在查询到ID的情况下，判断所述存储器中保存的ID是否有效。

由于分配的ID位于4-240之间，也就是说有效的ID必定是位于4-240之间的，反之位于4-240之外的ID是无效的。

通过本实施例，对于曾经获取到ID的设备，该设备可以将该ID保存到存储器中，从而在该设备重新上电后，可以获取保存在存储器中的ID，并在该ID有效的情况下，直接将该ID确定为第二ID后，广播DHCP Request报文。如此，避免每次重新上电设备都要重复申请ID。

以下结合图8介绍本申请以控制器局域网络的主控制器为主体的方法实施例，该实施例可以对应图1：

步骤310：接收到控制器局域网络的设备节点广播的DHCP Discover报文后，根据所述随机数分配一个可用的第一ID，并广播DHCP Offer报文；所述DHCP Offer报文中携带所分配的第一ID。

可选的，所述分配的ID位于4到240之间。

步骤320：接收到控制器局域网络的设备节点广播的DHCP Request报文后，判断该报文中的第二ID与之前所分配的第一ID是否一致。

步骤330：在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，将所述第二ID确定为第三ID，并广播DHCP Ack报文；其中，所述DHCP Ack报文中携带所确定的第三ID。

可选的，所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

与前述以控制器局域网络的设备节点为主体的基于控制器局域网络的设备管理方法实施例相对应，本申请还提供了基于控制器局域网络的设备管理装置的实施例。

本申请基于控制器局域网络的设备管理装置的实施例可以应用在控制器局域网络的设备节点上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图9所示，为本申请基于控制器局域网络的设备管理装置所在设备的一种硬件结构图，除了图9所示的处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该基于控制器局域网络的设备管理的实际功能，还可以包括其他硬件，对此不再赘述。

参见图10，为本申请一实施例提供的基于控制器局域网络的设备管理装置的模块图，该实施例从控制器局域网络的设备节点侧进行描述，所述装置包括：第一广播单元410、第二广播单元420、判断单元430和确定单元440。

其中，第一广播单元410，用于广播DHCP Discover报文；其中，所述DHCP Discover报文中携带一个随机数，所述随机数用作临时标识发送设备地址，所述控制器局域网络协议预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文；

第二广播单元420，用于在接收到控制器局域网络的主控制器返回的DHCP Offer报文后，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文；其中，所述DHCP Request报文携带所述第二ID；

判断单元430，用于在接收到控制器局域网络的主控制器返回的DHCP Ack报文后，判断该报文中的第三ID与所述第二ID是否一致；

确定单元440，用于在DHCP Ack报文中的第三ID与所述第二ID一致的情况下，将所述第三ID号确定为最终的ID。

在一个可选的实现方式中：

在所述确定单元440之后，所述装置还包括：

存储子单元，用于将所述最终的ID保存在存储器中；

相应地，

在所述第一广播单元410之前，所述装置还包括：

判断子单元，用于判断保存的ID是否有效；

所述第一广播单元410，还用于在保存的ID无效的情况下，广播DHCP Discover报文；

所述第二广播单元420，还用于在保存的ID有效的情况下，将该报文中的第一ID确定为第二ID，并广播DHCP Request报文。

在一个可选的实现方式中：

所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

类似的，与前述以控制器局域网络的主控制器为主体的基于控制器局域网络的设备管理方法实施例相对应，本申请还提供了一种基于控制器局域网络的设备管理装置的实施例。

参见图11，为本申请一实施例提供的基于控制器局域网络的设备管理装置的模块图，该实施例从控制器局域网络的主控制器侧进行描述，所述装置包括：分配单元510、第三广播单元520、判断单元530和第四广播单元540。

其中，分配单元510，用于接收到控制器局域网络的设备节点广播的DHCP Discover报文后，根据所述随机数分配一个可用的第一ID；

第三广播单元520，用于广播DHCP Offer报文；所述DHCP Offer报文中携带所分配的第一ID；

判断单元530，用于接收到控制器局域网络的设备节点广播的DHCP Request报文后，判断该报文中的第二ID与之前所分配的第一ID是否一致；

第四广播单元540，在DHCP Request报文中的第二ID与之前所分配的第一ID一致的情况下，将所述第二ID确定为第三ID，并广播DHCP Ack报文；其中，所述DHCP Ack报文中携带所确定的第三ID。

在一个可选的实现方式中：

所述分配的ID位于4到240之间。

在一个可选的实现方式中：

所述报文中的数据区定义了报文类型，所述报文类型占用1字节；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

综上所述，通过申请本实施例，借鉴了DHCP入网报文，在控制器局域网络协议中预先定义了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck报文。如此，控制器局域网络的设备节点与主控制器可以实现DHCP报文交互，即与DHCP入网报文类似的，设备节点可以广播携带随机数的DHCP Discover报文；主控制器可以根据所述随机数分配一个可用的第一ID，并通过DHCP Offer报文广播出去；设备节点接收到DHCP Offer报文后将所述第一ID作为第二ID后，通过DHCP Request报文广播出去；主控制器在所述第二ID与第一ID一致的情况下，将所述第二ID作为第三ID并通过DHCP Ack报文广播出去；最后设备节点在判断所述第三ID与第二ID一致的情况下，将所述第三ID确定为最终的ID。这样，实现了控制器局域网络可以自动地对接入的设备分配ID，实现了提高分配ID的效率，并且由于无需人工分配ID，相应地也降低了运营成本。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。