技术领域
[0001] 本发明属于监控技术领域，具体涉及路灯监控系统。
相关背景技术
[0002] 目前的智能路灯主要有基于电力载波(PLD)的智能路灯系统和基于zigbee无线通信的智能路灯系统。基于电力载波(PLD)的智能路灯系统由于不能跨越配电变压器使用，再加上稳定性和保密性都不佳，导致使用范围受到很大的局限。基于zigbee无线通信的智能路灯系统由于zigbee的路由深度只有15跳，即一个zigbee网络只能有15个协调器，假设每个节点的无线信号覆盖距离可以达到200m，则一个zigbee网络能覆盖的极限距离为200*15＝3000m，其通信距离有限。总之目前的智能路灯的通信距离有限，稳定性较差。
具体实施方式
[0027] 在下文中，将更全面地描述本公开的各种实施例。本公开可具有各种实施例，并且可在其中做出调整和改变。然而，应理解：不存在将本公开保护范围限于在此公开的特定实施例的意图，而是应将本公开理解为涵盖落入本公开的各种实施例的精神和范围内的所有调整、等同物和/或可选方案。
[0028] 在下文中，可在本公开的各种实施例中使用的术语“包括”或“可包括”指示所公开的功能、操作或元件的存在，并且不限制一个或更多个功能、操作或元件的增加。此外，如在本公开的各种实施例中所使用，术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。
[0029] 在本公开的各种实施例中使用的表述(诸如“第一”、“第二”等)可修饰在各种实施例中的各种组成元件，不过可不限制相应组成元件。例如，以上表述并不限制所述元件的顺序和/或重要性。以上表述仅用于将一个元件与其它元件区别开的目的。例如，第一用户设备和第二用户设备指示不同用户设备，尽管二者都是用户设备。例如，在不脱离本公开的各种实施例的范围的情况下，第一元件可被称为第二元件，同样地，第二元件也可被称为第一元件。
[0030] 应注意到：如果描述将一个组成元件“连接”到另一组成元件，则可将第一组成元件直接连接到第二组成元件，并且可在第一组成元件和第二组成元件之间“连接”第三组成元件。相反地，当将一个组成元件“直接连接”到另一组成元件时，可理解为在第一组成元件和第二组成元件之间不存在第三组成元件。
[0031] 在本公开的各种实施例中使用的术语仅用于描述特定实施例的目的并且并非意在限制本公开的各种实施例。除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本公开的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本公开的各种实施例中被清楚地限定。
[0032] 实施例1
[0033] 如图1所示，本发明实施例提供了一种路灯监控系统，包括：
[0034] 管理客户端10、云端服务器20、网关30和路灯40。
[0035] 路灯40包括：基于macbee light link协议的控制器401和可控光源402。
[0036] 网关30与路灯40通过网络拓扑结构进行自组织网络连接。
[0037] 网关30与路灯40之间通过macbee light link协议进行通信。
[0038] 网关30与云端服务器20通过UDP协议进行通信；网关30与云端服务器20之间的连接可以通过移动基站的移动数据连接，也可以通过有线网络或者wifi。
[0039] 网关30用于实现macbee light link协议与UDP协议之间的数据转换。
[0040] 云端服务器20用于对路灯40和网关30进行汇总管理。
[0041] 管理客户端10用于对路灯40进行可视化监控管理。
[0042] macbee light link是一种改良的macbee协议，主要针对路灯应用场景设计了可自组网、无线信号最大可中继2048次。
[0043] 路灯监控系统中使用的报文类型主要包括如下类型：
[0044] Type0：SRV2NET(服务器->路灯)Broadcast(广播)
[0045] Type1：SRV2NET(服务器->路灯)Multicast or Unicast(组播/单播)[0046] Type2：DEV2SRV(路灯->服务器)unicast ack(路灯回复服务器)
[0047] Type3：DEV2SRV(路灯->服务器)unicast report(路灯主动上报)
[0048] Type4：SRV2NET(服务器->路灯)unicast report ack(服务器回复路灯)[0049] Type5：DEV2DEV(路灯->路灯)
[0050] 各种报文类型对应的报文头部定义如下：
[0051]
[0052] 其中：type表示报文类型，hop表示中继次数，addr表示报文源地址，报文被中继后，源地址不能改变；seq表示报文编号。每种类型的报文头部都包括报文类型type、报文源地址addr和报文编号seq，根据报文类型、源地址和报文编号来判断收到的报文是否重复。
[0053] 每条报文都可根据type+addr+seq唯一确定，当收到某一报文后，缓存该报文信息中的以上这3条信息。在一定时间内如果再收到这3条信息一样的报文，则认定此报文已经收到过。
[0054] slot表示时槽，本协议默认一个时槽slot＝62.5ms，即1秒被拆分成了16等份。hop表示无线信号的中继次数，这个变量值会保存在报文中，无线信号每被中继一次，hop则增加1。
[0055] 报文由云端服务器20发送给路灯40称为下行报文。报文由路灯40发送给云端服务器20称为上行报文。路灯与路灯直接报文交互，且报文不会被中继，这种通信方式定义为邻居通信。
[0056] 为避免无线信号冲突，对每个slot中的时隙进行了划分，时隙划分如下：下行时隙：用于发送下行报文；上行时隙：用于发送上行报文；竞争时隙：用于邻居间通信。下行时隙占整个时槽的1/3，上行时隙占整个时槽的1/2，竞争时隙占整个时槽的1/6。
[0057] macbee light link协议采用对报文进行中继判断处理。
[0058] 基于macbee light link协议的控制器上的MLL(macbee light link)模块的无线发送功率有限，只有附近控制器上的MLL模块才能收到报文，所以需要报文中继转发才能实现最远端路灯的控制器上的MLL模块收到报文。
[0059] 每个MLL模块都要对报文进行中继判断并处理。中断报文处理流程如图2所示：S101、收到MLL发送的报文；S102、判断报文是否需要中继；具体可根据报文头部中的type字段来判断；不需要则直接结束。当需要中继时则执行S103、判断报文是否是新报文。判断报文是否是新报文可根据收到的报文源地址(addr)以及报文编号seq和设备缓存的addr和seq做比较，当两项都一致时则判定为收到的报文不是新报文；当判断为新报文时执行S107、记录第一次收到此报文的hop及其他相关信息，然后把报文中hop加1，然后把报文添加到发送队列，设置发送开始时间为下一个slot对应的上下行时隙；S111、判断是否需要保证可靠中继，如果需要，则执行S112、调用可靠中继处理模块处理，S114、中继报文发送时间到来后，将中继报文发出。
[0060] 当判断报文不是新报文，则执行S104、与缓存的报文进行相关信息比较；S105、判断此报文是否已经转发了；如果此报文已经转发了则直接结束，如果此报文没有转发，则执行S106、判断hop是否与第一次收到此报文的hop相同，如果相同则结束，不相同则执行S108、判断hop是否与第一次收到此报文的hop大1，如果判断hop与第一次收到此报文的hop大1，执行S109、判断是否收到过比第一次收到此报文的hop大1的报文，如果已经收到过则结束，如果没有收到过则执行S113、发送开始时间在原基础上再增加一个slot。如果判断hop不是与第一次收到此报文的hop大1，则执行S110、判断是否收到过比第一次收到此报文的hop大2或者更大的报文，如果收到过直接结束，如果没有收到则执行S113、发送开始时间在原基础上再增加一个slot。
[0061] 可靠中继处理模块的处理流程如图3所示：S201、将需要做可靠中继的报文缓存(根据上、下行分开缓存)，重置接收列表；S202、等待接收邻居回复；S203、收到邻居对接收到中继报文的回复；S204、更新接收地址列表中的邻居地址和其他信息；S205、将接收列表中的邻居地址和邻居关系中的邻居地址做对比，判断所有邻居是否都收到此中继报文；S206、判断可靠中继是否完成，当可靠中继没有完成时，则执行S207、将需要做可靠中继的报文添加到中继发送队列等待发送。
[0062] 报文中继没有路由功能，大大加快了报文传递速度。
[0063] 路灯40在出厂时设有一个和云端服务器20对应的私有秘钥；在路灯40正式接入云端服务器20后，云端服务器20会随机分配一个公共秘钥，云端服务器20不定时对所述公共秘钥更换。
[0064] 路灯40入网时云端服务器20会通过广播地址给路灯40下发加密后的公共秘钥，只有对应的路灯才能通过私有秘钥解开。
[0065] 路灯40入网后的所有通信报文都通过公有秘钥加密，只有属于该网络的设备才能正确解密此报文。
[0066] 加密算法采用TEA加密算法，秘钥长度为128位。
[0067] 无线数据采用CRC校验和TEA加密技术保证了数据的正确性和安全性。
[0068] 路灯40接入所述路灯监控系统统一采用云端服务器20的系统时间，系统每隔10-30分钟会进行一次全网对时。
[0069] 路灯40接入所述路灯监控系统统一采用云端服务器20的系统时间，对时采用特殊算法来避免信号中继带来时间不准确，保证最终达到所有设备时间误差不超过1秒。另外，为避免各个路灯各自的时钟差异导致运行一段时间后时间误差增大，系统每隔10-30分钟会进行一次全网对时。
[0070] 每个MLL都会记录收到上行报文的最大hop和下行报文的最小hop，然后把上行报文最大hop和下行报文最小hop相加得到hop_max，再按照冗余算法得到一个表示网络的最大hop值。收到下行报文的最小hop可以表示此MLL到最近路灯网关的距离，最后根据网络的最大hop_max和设备自身的hop_dev来分配保活时隙。
[0071] 路灯40定时主动上报路灯保活报文给云端服务器20，所述路灯保活报文里附带有路灯20的亮度状态信息。
[0072] 路灯保活报文里直接附带上灯的亮度状态。MLL协议具有独有的保活方式，由于一条道路的路灯安装型号基本一致，而且亮度状态基本一致。且邻居间通信可以互相通告彼此状态，所以，一条保活报文最可能多地附带上邻居的当前状态。同时邻居收到自己状态被上报且正确，则此次保活时隙不再发送报文。
[0073] 路灯保活报文的格式如下：
[0074]len state addr0 … addrn
[0075] addr0-addrn：MLL模块地址，在整条道路中具有唯一性。
[0076] state：记录路灯当前状态，由于addr0至addm的状态都相同，所以都共用一个state。
[0077] 路灯保活优先采用路灯主动上报的方式，由于保活报文每隔一段时间都会发送，没有采取可靠中继的方式，为保证云端服务器对路灯在线状态判断的正确性和及时性，还可以增加了被动上报保活的方式。被动上报保活需要云端服务器的回复确认。
[0078] 路灯40的工作状态异常时，路灯40将通过主动上报方式给云端服务器20上报异常信息，当所述路灯收到所述云端服务器的确认回复后停止上报所述异常信息，否则每个上报周期都会主动上报一次直至收到所述云端服务器的确认回复信息。
[0079] Zigbee协议由于协议设计的缺陷，状态和异常都只能主动查询，系统越大，响应时间就会越长。而基于MLL协议的路灯系统采取的是主动上报方式，而且是可靠上报，必须在收到服务器的回复后才停止，否则每个上报周期都会主动上报一次。
[0080] 状态回传及时、异常上报及时，状态和异常通过主动上报的方式，不像zigbee那样需要挨个去查询。
[0081] 路灯具有一个全球唯一的序列号，所述序列号信息以二维码形式印制在路灯上，在所述路灯安装时，通过具有定位功能的移动终端上安装的APP扫描路灯上的二维码，移动终端会将采集的位置信息以及路灯信息上传到所述云端服务器。这样便实现了路灯的位置定位。为保证位置的准确性，APP可以通过自动定位和人工确认相结合的方式来采集位置信息。本实施例中，移动终端可为手机、智能便携式电子设备、IPAD等。
[0082] 路灯通过移动终端APP定位，安装操作简单，方便施工。
[0083] 管理客户端10采用web方式接入云端服务器20进行可视化管理。
[0084] 管理客户端采用web方式，只需要通过浏览器就能操作管理，支持PC和移动设备，管理更加方便。
[0085] 路灯监控系统的安装使用的流程如下：
[0086] 路灯安装，同时用移动终端扫码上传路灯相关信息到云端服务器；
[0087] 厂家通过专用的管理后台对路灯和网关授权；
[0088] 用户通过管理客户端操作组网；
[0089] 用户通过管理客户端设置路灯控制策略和异常处理配置。
[0090] 路灯存储有对路灯的控制策略。
[0091] 每个路灯存储有各自的对灯的控制策略，即使通信中断也不会影响照明控制。
[0092] 该路灯监控系统不仅可以应用于路灯照明，还可用于车站、铁路、园区以及地下车库等应用场景。
[0093] 本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。
[0094] 本领域技术人员可以理解实施场景中的设备中的模块可以按照实施场景描述进行分布于实施场景的设备中，也可以进行相应变化位于不同于本实施场景的一个或多个设备中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
[0095] 上述本发明序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
