前言
随着通信技术，特别是物联网通信技术的快速进步，“路灯单灯控制”这个概念早已在行业内深入人心。相关产品和技术不断涌现；大量工程项目落地实施；创造了积极的经济效益和社会效益。但是，在路灯单灯控制产品中，有一个技术细节——“单灯控制器本地存储定时策略”——却被大多数技术开发者及用户所忽视。
而对这个细节的“忽视”，却隐藏了巨大的公共安全隐患。不仅会让我们的公共照明系统，存在因系统故障导致“失控”的风险；甚至会在“人为故意破坏”、“自然灾害”甚至“战争”等极端情况下，成为危害城市公共安全的定时炸弹。
1“单灯控制器本地存储定时策略”的由来
早在LED调光电源问世之初，就有一些调光电源产品具备了一个“红外程序烧写口”，用于写入功率调节的“策略”（即通电后多长时间降功率）；例如，通电后4小时后降为半功率运行。以此，在LED灯具节能的基础上，实现二次节能。再后来，随着“单灯控制”技术的日趋进步，应用数量越来越多，这一“本地策略运行”的模式也被习惯性地“移植”到了单灯控制器中。
同时，目前主流的单灯控制技术，都或多或少地存在“通信实时性较差”的问题，造成路上灯具远程控制一致性差，用户观感体验很受影响。而“单灯控制器本地存储定时策略”，这种本质上属于“定时控制”的方法，又可以在一定程度上弥补“控制不整齐”的弊端。所以，目前绝大多数单灯控制产品，将这一控制方式保留了下来。甚至，很多“招投标文件”中，会把这一功能作为技术要求列出，作为必要的考核条件。
2技术原理
这种控制方式的原理非常简单，以我们目前最常听到的主流单灯控制技术NB-IoT为例：
由于受限于通信技术本身的“高延时”特性，采用NB-IoT通信方式的单灯控制器在控制实时性方面普遍较差。因此，远程管理平台会预先设置好开关灯或调节功率的时间表（控制策略），在单灯控制器与服务器建立通信后，将这个时间表更新给单灯控制器。尽管单灯控制器不能和服务器保持很好的“实时沟通”，但是每隔一段时间还是可以与服务器“握手”一次，以获取新的“运行时间表”。
这样，每台单灯控制器就可以按照同一套本地时间表“离网”运行，用户观感上也就会觉得控制还是比较“整齐”的。
但是，本质上来说，这种控制方式其实还是“定时控制”。只不过是“控制时间表”可以远程修改罢了。
3危害
首先，我们介绍两个在实际工程案例中遇到的真实情况。
第一例：
2017年，北方某城市单灯控制项目。项目投入运营初期，现场工人依旧按照传统的“开灯巡检”模式排查灯具故障。巡检班组白天给路灯供电回路上电准备巡查灭灯情况，但由于单灯控制器本地存储了定时策略，路上灯具无法正常在白天点亮。且由于远程管理平台，修改定时策略的实时性较差，无法短时间内做到100%修改成功，最终导致当日巡检工作被迫停止。
第二例：
2019年，华中某城市单灯控制项目。某路段集中控制器因故障拆除没有补装。前期因考虑到节约电能，该路段单灯控制器本地存储了上电后4.5小时关灯的定时策略。后期因为附近高铁施工，该路段工程车辆整晚作业，路灯需要整晚开灯。但由于短时间内无法补装集中控制器，导致无法更改单灯控制器内存中的“控制时间表”，最终只能耗时近一个星期，将单灯控制器全部拆除。
从上面这两个案例可以看出，当单灯控制器因故不能与管理平台通信时，依旧按照其内部固有的时间表“自主”控制路灯，会给路灯的正常管控造成非常大的不便甚至安全隐患。
那么，本文标题中“危害城市公共安全的定时炸弹”，是不是“危言耸听”呢？我们不妨通过下面一个假设的极端场景，来体会一下。
假设场景：
C国某城市30万盏路灯全部安装带有“本地定时策略存储”功能的单灯控制器；A国黑客悄悄黑掉了该城市的路灯管理服务器，并且修改了30万盏路灯的本地定时策略，将其设置为晚上17点以后关灯；夜幕降临，17：30，C国某城市路灯供电回路上电，30万盏路灯点亮，单灯控制器获取到时间信息后，立即按本地定时策略将所在路灯关闭，几分钟后30万盏路灯全部熄灭，该城市一片漆黑；此时该城市路灯管理部门发现路灯管理平台已遭破坏，无法远程更正单灯控制器本地定时策略。面对全城一片漆黑，束手无策！
通过上面这类极端场景的推演，我们可以感受到，“单灯控制器本地定时策略存储”这颗“炸弹”的威力。
4对策
针对上文描述的“隐患”，有些技术专家会也给出了“解药”：可以设置一些限制条件，例如单灯控制器与远程服务器失联一定时间后，即放弃执行本地控制时间表。但是，如果这样做，又带来了其他问题：失联多少时间后放弃本地时间表？这个“失效时间”谁来定义？如何定义？这个“失效时间”如果可以通过远程服务器修改，再次被人非法编辑了怎么办？其实，我们应该清楚“魔高一尺，道高一丈”这个道理。只要在单灯控制器内部预留了“时间表控制”这样的功能模块，这个“漏洞”就可能被人非法利用。
反过来说，如果要保证绝对安全，那就不能预留这样的功能。
路上照明设备的任何“关灯”和“降低功率”等可能会影响道路照明安全的动作，都需要远程管理平台的实时指挥和授权。
做到了这一点，就可以最大程度地避免“极端 事故”的发生。
我们还是用前面那个假设的极端场景进行推演：
C国某城市30万盏路灯使用的单灯控制器，硬件上即不支持“本地定时策略存储”功能，路灯的定时策略全部由管理服务器远程定时下发；
A国黑客悄悄黑掉了该城市的路灯管理服务器，并且修改了30万盏路灯的远程服务器定时策略，将其设置为晚上17点以后关灯；
夜幕降临，17：30，C国某城市路灯供电回路上电，30万盏路灯点亮并上报状态，服务器检测到单灯上报的开灯状态后，按照A国黑客预设策略实施关灯动作，将30万盏路灯全部关闭，该城市一片漆黑；
此时该城市路灯管理部门发现路灯管理平台已被破坏，随即切断服务器电源及网络，同时立即安排全部工程人员上路，将所有供电回路人工断电后重新上电，所有单灯控制器断电重启后，即恢复默认亮灯状态；
如此应对，一小时之内，市中心主要干道即可恢复正常道路照明。大约2小时后，全市30万盏路灯全部恢复正常点亮。
同样是极端的黑客破坏，但是没有“单灯控制器本地存储定时策略”功能的系统，短时间内即可完全恢复道路照明，将破坏的危害降至最低。
5总结
作为一个灯联网通信架构设计者，我认为，当路灯远程控制平台任一环节出现故障（平台、通信、现场硬件），都不应导致传统的“回路开关”控制方式失效。换句话说，任何所谓的“高科技”附加功能，都需要在设计之初充分考虑到“降级使用”的概念。即使“高级功能”因故障失效，还要保障“初级功能”的有效和可靠；避免因过度依赖“高级功能”，而在极端情况发生时，导致系统性“全面失控”。
照明行业的各位前辈，请大家认真评估一下自己做过的单灯控制项目，您曾经选择的技术方案，是否在极端情况发生时依然有足够的应对能力，保障城市公共照明的绝对安全？
 |
