从“路灯远程管理”这个产品属性出发，“灯联网”的基本任务就是实现“远程控制+信息采集+自动化运行”。也就是行业内很久以前就有前辈提出的“三遥”概念，即所谓的“遥控”、“遥测”、“遥调”。“三遥”做的好不好，落实到“单灯”层面，就是考验灯联网平台内单个通信节点，即单灯控制器，的“通信能力”。如何评价一套灯联网平台中，单灯控制器的“通信能力”？我们觉得从以下三个基础指标来判断比较能说明问题：
1.通信速率
“灯联网”这个应用，对“通信速率”的要求是很低的，因为网内需要传输的数据基本是控制命令及查询上报的灯具运行状态参数，数据量很小。目前主流的灯联网解决方案都可以满足。
2.通信实时性
这个指标是根据实际使用体验及具体需求决定的。我们认为数据下行（可以理解为管理平台下发控制命令到单灯控制器）实时性应在2秒钟之内；数据上行（可以理解为单灯控制器上报数据到管理平台）实时性应在2分钟之内。
如此定义的理由如下：
当对路灯实施远程控制时，路上灯具的动作要有良好的“一致性”，否则路灯开启一致性过于“离散”会影响道路用户的感官体验，甚至造成因道路照明设施开关引起的持续视觉“干扰”，导致交通事故发生。
当现场路灯运行状态异常时，单灯控制器应该“及时”将故障信息报送管理平台，以提高维护人员维修效率。尤其是一些极端严重故障发生时，例如高压、大面积断电、漏电等，能够更快更准确地将故障信息发送给维护人员，可以最大程度地减小现场设备损失，甚至避免现场人员的伤亡。
这里针对远程控制的“一致性”我还要补充一点：不应将日常控制策略（开关和调光的时间）直接写入现场单灯控制设备。其实，绝大多数单灯控制解决方案都是把日常控制策略保存在单灯控制器中的，主要是为了弥补单灯控制器通信实时性不好的弱点。控制时间保存在“灯头”里，即使“灯头”在实施控制的时间点不能通信，也可以做到“按时开灯”，现场的控制一致性表面上得到了保证。但是这个方案存在严重的安全隐患。可以想象，当灯联网管理平台任一环节故障（平台服务器故障，运营商通信基站故障，单灯控制器现场通信故障等等），且现场遇有重大活动、异常天气状况、意外事故，路面照明需要人工接管手动控制时，如果“灯头”内部存有控制策略，这个“灯头”就会处于“失控”状态，即无论回路如何控制，它都只会按照预设的程序自主运行；这样就有可能因为道路照明设备的失控，引发重大公共安全事故。
这里引述一段某市路灯管理部门领导的话：节能减排智能管理必须服从于“公共照明安全”这个基本原则；任何一种技术的应用，都要保证“路灯传统回路开关控制”的可靠性不受影响。我们认为这句话讲的非常中肯，应该成为行业内的普遍共识。
3. 通信可靠性
能满足上述要求的“通信速率”和“通信实时性”的单灯控制器，在灯联网管理系统中我们定义其为“在线”。那么对灯联网管理平台中单灯控制器通信可靠性的要求，应该是在线率≥98%。这个比例也是一般城市道路照明管理部门对亮灯率的普遍要求。
满足了以上三个基础指标的通信系统解决方案，就可以认为是一套“可行的”灯联网通信方案了。在此基础上，还有一些“基本功”是应该被考虑的。
4. 灯与灯之间的直接信息交互能力
这个能力，用现在比较时髦的一个词来说，其实就是“边缘计算”能力的一部分。即，信息的采集、处理和反馈都在现场设备之间完成，无需“惊动”管理平台。局部动作完成之后，在合适的时候把这次局部动作的信息“同步”到管理平台即可。这么做的好处是显而易见的：首先，信息处理速度更快；其次，解决局部问题调用的资源最少。
“边缘计算”这个概念在灯联网系统中有一个很典型的应用实例：路灯的精准按需照明。即，通过单灯检测人流车流，单灯控制器将获取的人流车流信息与附近的其他单灯控制器交互分享，其他单灯控制器通过自己的位置来确定是否要“变亮”以及“亮多久”。
反过来想，如果类似需求完全依靠管理平台做“中心化”决策，随着灯联网覆盖范围的增加，这个通信和信息处理的工作量，管理平台肯定是“吃不消”的。
5. 工信部52号公告
任何一套灯联网通信解决方案，如果是无线通信方案，在中国大陆地区使用，还必须接受“国家标准”的监督和管理。工信部2019年11月发布的第52号公告，相对于信息产业部2005年发布的相关微功率无线电设备的技术要求（信产部〔2005〕423号），做出了较大幅度的调整。还请各位选择方案时擦亮眼睛，不要违规啊。
留言列表