本文适合对软硬件技术和物联网架构都有深入了解和实践的专业人事阅读。
考虑一个简单的使用场景：一个过道顶安装一个人体运动传感器（幻腾产品UFO），用来控制两盏智能灯（幻腾产品Nova）。当有人经过时，UFO可以检测到人的运动，从而控制Nova点亮到100%亮度；当人离开后，UFO检测不到人的运动，Nova亮度降低到20%。UFO和Nova之间采用无线通讯，之间并没有线缆连接。此外UFO是由纽扣电池供电的低功耗设备，需要有长达若干年的设计电池寿命。
上面这个场景，有三种实现方式：
- 大闭环：UFO将检测到的有人/无人状态发送到云服务器，云服务器根据IFTTT策略向Nova发送控制指令；
- 小闭环：UFO将检测到的有人/无人状态发送到本地网关或中控设备，中控设备根据IFTTT策略向Nova发送控制指令；
- 最小闭环：UFO直接向Nova发送控制指令
其中，方式1扩展性最强，但控制延时不确定，有时可能长达1~2秒。这样的延时对于IoT控制来讲，体验非常差。方式2延时较短，但引入了复杂的本地中控设备，不仅成本高，而且是个“单点失效”的设备——一旦中控设备不稳定，就会导致整个系统瘫痪。智能系统瘫痪后，连传统的开关灯都无法实现，这是不能接受的。
幻腾Local Control固化控制协议，采用的是上述方式3的控制方式。这样，只要Nova有电，控制就可以达成。它不依赖于网关或中控设备是否联网，甚至不依赖于网关是否通电开机。网关仅仅作为云端控制和收集统计数据的桥梁使用。
这好像并不复杂呀，人体运动传感器相当于一个遥控器嘛？
如果你曾经尝试过给一个四路或者六路的电动窗帘遥控器对码，你一定清楚这是一个多么痛苦的过程。幻腾将“遥控器”和“执行器”的控制策略保存在云端，并通过Topology Generator为每个设备生成需要的分布式控制策略，并可靠地同步到设备上。这样，用户只需要通过手机APP或者幻腾后台，就可以对固化控制关系进行更改。这和对码相比，即方便又安全。
有点意思，不过仍然不难实现。好，那我们把场景的复杂度提高一些：
还是走廊里的两个Nova灯，我们现在需要用两个UFO来控制，分别放在走廊的两头。我们希望，只要其中任意一个UFO检测到有人经过，就应该打开灯；但只有当两个UFO都检测不到人时，才减弱灯光。即：
- 灯光明亮条件：UFO1或UFO2有人
- 灯光减弱条件：UFO1和UFO2都无人
如此一个简单的与、或算符，该在哪里执行？如果采用大闭环或小闭环，那么云服务器或中控设备将毋庸质疑地担当“重任”。但我们不喜欢延时和单点失效，事情就变得复杂了。
值得一提的是，现在另一种单点失效的形式是：其中一个UFO在有人的状态下突然坏掉了，这时系统可能认为这个UFO一直处于有人状态，因此灯光总是不会变暗。这也是不能接受的。常理告诉我们，走廊中的人不会长时间停留，所以如果一个UFO长时间（比如超过4个小时）未上报无人，那么它应该是坏掉了。对于坏掉的UFO，默认情况应该认为是无人的，这样可以不影响整体策略的执行。
我们继续提高复杂度：
假设走廊尽头有一个SNPi按钮开关，它是一个无线按钮，并不会接通和断开Nova的电源，而是在被按动时，通过无线电给系统发送指令。现在我们希望，当SNPi按到“关闭”位置时，无论两个UFO是否有人，Nova都不点亮；当SNPi处于“开启”位置时，UFO可以控制Nova的亮暗。
- 灯光明亮条件：SNPi开启，并且UFO1或UFO2有人
- 灯光减弱条件：SNPi开启，并且UFO1和UFO2都无人
- 灯光关闭条件：SNPi关闭
看起了我们的表达式变得更加复杂了。那么，是否支持任意复杂的逻辑表达式，就可以解决问题了？并不是。
我们继续给走廊增加一些动感：当有人从UFO1这边走进走廊时，Nova1先亮起，接着Nova2亮起；当有人从UFO2这边走进时，则先点亮Nova2，再点亮Nova1。此外，上面的SNPi开关逻辑仍然存在。当然，我们也可以用更多的Nova，使走廊灯光形成跑马灯逐个点亮的效果。这样一来，控制加入了时间的维度。
现在，你会想：灯里面不是都有MCU嘛，可以给每个灯设计定制的程序，那样就可以实现任意的效果。
是的，但那样是不可扩展、不可持续维护的系统。利用幻腾的Local Control系统，并不需要定制每个灯的固件，不需要MCU编程。只需要用市面上买到的Nova，就可以实现上面这些复杂的场景。当然，复杂的场景仍然需要专业人员的配置，不过大部分配置的工作量都可以通过电脑在云端完成。
这就是幻腾Local Control系统的能力——一个分布式控制系统。它无延时、无单点失效、可以通过云端配置、具有无限扩展性。