又闭门造车了半年多，想重新整理一下自己对物联网的一些想法。

关于物联网究竟是什么

物联网是互联网的“无界超集”，但其实也只是实体通过协议连接而成的网络

虽然互联网当今已是异常庞大，但归根结底互联网是以一组通用协议连接计算机及路由器、交换机等所形成的的网络。我们将互联网进行无限扩展，变成以任意协议链接任意实体时，该网络即变成了物联网。

协议

即机器进行沟通交流的表达方式，用于实体间数据传递，等价于人类的语言。和人类所处的地理环境与文化导致语言差异类似，各种协议的诞生源自适配不同的：

• 物理介质
• 电流还是电磁波？有线还是无线？
• 通信距离
• 数据传输两端间距离1厘米还是100公里？
• 数据结构
• 1b的开关量还是10MB的卫星图像？
• 硬件配置
• 单片机还是x86服务器？
• 通信需求
• 单工、双工还是半双工？
• ...

再算上人为的企业生态争夺等原因，各种条件排列组合便促成了各色的协议。实际协议还继续可以细分为物理层通讯协议（只管数据正确抵达）和应用层通讯协议（只管正确编码、解析数据），感兴趣的话可以再看看 OSI 七层模型。

然而，仅通过单协议几乎不可能把数据从源头直接送至终端，哪怕看上去很合理。比如摄像头vs屏幕，话筒vs音响，温湿度传感器vs液晶LED。原因也很简单，发送方设备关心的是如何保证数据完整高效地传递给对方，以最大程度保护数据质量；接收方设备关心的却是如何兼容并执行各类源头的数据，以最大化产品的适用范围。

所以当设备变多、业务需求变复杂时，任何两端的设备间都可能存在大量不同协议，于是应对各类协议就变成了最棘手的问题之一，甚至我们会需要专门的设备进行协议的整合，形态类似于互联网中的路由器与交换机。另外，一个协议的诞生往往需要一个行业的龙头企业或联盟倾注几十年心血研讨，从理论上也不可能设计出一招鲜吃遍天的完美通用协议，即便是大名鼎鼎的TCP/IP在很多条件下也极其受限。所以我认为仍该把主要精力投入到物联网实体中。

实体

即机器本身，但实际也不限于电子设备。各种机械机关，甚至生物驱动的装置都可属于这个范畴。例如电脑、手机可以作为物联网中的实体；蓝牙耳机、电钢琴、3D打印机也是；电机、传感器、摄像头、开关也是；但是如果我有一串多米诺骨牌，收到信号后自动碰倒第一张，末端再接着3个开关，我认为也可以作为物联网的一个实体；在美洲大蠊头上插两块电极进行操控，或是自动观测动物行为以预测天气，其中的动物我认为也都可算作物联网中的一个实体。

总而言之，我认为判断是否可成为物联网中实体的关键点是在数据的生产、消费和处理上。

生产者实体

比如温湿度传感器、IP摄像头、麦克风、雷达等，都具备一个共性，即：将环境中某些物理量进行观测、量化、发送。这类实体生产数据以驱动一切物联网业务的逻辑。本着GIGO原则（垃圾进、垃圾出），生产的数据质量必然会直接影响整个物联网系统的产出。然而这一点很容易被忽略。曾经我个人就有过试图用IMU+摄像头复现一个SLAM算法，结果差的一塌糊涂，调试半天无果。最后发现IMU的选型价位和原作差了几十倍，数值精度和时序精度严重影响了算法结果。类似场景也经常出现在机器学习的任务中，算法一套花里胡哨往往不如多点数据，一堆数据往往也会因为里面几个错误标注毁了一锅粥。

消费者实体

或终端，比如耳机、屏幕、空调、电梯、电动门等，他们的共性是在接收到数据后对物理环境进行某种程度的干涉，以达到对人有益（或有害？）的目的。其结果可以是维持环境指数的稳定，或复刻人类的行为以自动操作物理设备，或将数据转化为人类可接收的样式（可见光、声波等）。一般来讲，终端设备相对更容易设计与测试，毕竟是最靠近业务需求的一端，所见即所得。麻烦的部分来自于它们的行为完全依赖输入的数据，因此同样适用于GIGO原则，一旦输入数据有误，那它们对物理环境的干涉就可能出现重大偏差。轻则耳机爆音、屏幕雪花，重则电梯下坠、电动门夹人、核电站自爆，工业中绝大部分的致命事故都来自于人为操作失误或逻辑设计缺陷，并且能力越大潜在的危害就越大。

因为生产者实体往往受限于材料学、半导体工艺等限制而发展缓慢；而消费者实体也受限于物理定律，同样经常依赖基础科学的发展，并且很难通过自身规避错误数据输入的危害。所以我认为处理者实体是目前物联网发展的真正突破口。它不受制于客观物理环境，而是纯粹逻辑的堆砌，需要的仅仅是创造力和智慧，潜在发展空间巨大。

处理者实体

比如逻辑门、集成电路、单片机、FPGA、服务器、超算等。无论听上去多复杂，他们的目的就一个：对数据进行接收、处理、发送，区别只是能力越大责任越大。但就单单“处理”实际也已经包含了一个宇宙，它可以是数据透传（即数据内容不做改变，只做协议转换），也可以是汇集网络内一切数据进行“大格局的统筹”再去指挥机器甚至人类，复杂度与功能性的天花板可以说无限高。

之所以我认为处理者实体是当前最值得倾注精力的部分，是因为得益于计算机技术的猛烈发展，它的研发成本低、自由度高、不受限于物理环境，将其他两类实体的困难转嫁过来往往能起到四两拨千斤的效果。

比如可以利用处理者强化生产者。举个例子来说，从自然界采集可见光是无法直接获取光源距离的，但只要再加入一个采集点并测量它们相对的位移，就可以通过算法（对极几何）去推算出真实距离，使其从可见光传感器变成了深度传感器；声波也同样如此，引入麦克风矩阵后甚至可以在千人会场中判断说话者的位置。实际目前绝大部分先进的传感器都经过了类似的“强化”，只是被集成封装在了一起。如果想获得更大的能力，就需要将其解耦出来，通过利用更密集的计算资源进行统一处理，比如最近几年流行的边缘计算就属于其中的一个方案。

再比如还可以利用处理者强化消费者实体。刚提到关于验证数据的正确性和危害防范就是个很好的例子，例如耳机在发出声音前加入判断输入声波音量的逻辑，防止损伤耳膜；在工业中用例更多，小到电机、机械臂，大到流水线、变电站，设备依照输入数据做出行动之前几乎都需要“三思而后行”。但是无论如何设计（尤其考虑到成本），设备自身的感知能力也都有限，通过集成传感器和逻辑处理芯片只能解决一小部分的问题。例如机械臂是无法得知它臂长范围内有没有人的，大型传送带也感知不到上面是人还是物品。这时候大家自然而然想到的就是借助额外传感器来辅助判断，比如放置广角摄像头或红外线人体探测器。但是针对每个设备都安排一套并不现实，物料与研发成本都过大。于是我们再次将其解耦，同一组传感器可以接入不同逻辑，去用各自方式指导不同的机器。在此物联网的价值已经初见端倪。

人在物联网中的角色

通过物联网实现自动化是一方面，但总归用之于人。所以处理者最大的价值我认为还是数据处理本身，也就是将数据进行压缩、抽象、分析、复制、传递等等，以碎片数据为砖瓦筑起信息城池。在这里人才是真正的数据消费者实体，也就是物联网的真正终端。

人类无法大幅提升自己干涉自然的能力，否则就变身成了超能力者，但通过物联网却可以轻易获得感知自然的能力。虽然人们可能已经习以为常，但你打开手机看了眼气温和天气预报时，你已经间接接收了上百G甚至几十T的数据量；看了眼地图上的堵车情况就已经间接查询了数千万项的车流量时序信息。所以随着网络内的传感器数据生产者增多，人们理论上可以获取的信息就会越全面，自然就更容易做出正确的决策，直接提升人的生活水平与生产力。例如最近北京全市每日核酸，我就期待着有一个能实时显示各检测点排队人数的应用，可以错峰检测，避免大家太阳暴晒下排几十分钟的队（遗憾的是虽然有心做却没能找到渠道）。

当然，处理庞大的数据量并不简单，精炼成人类可读的报告更加困难。目前成熟的方案一般仅存在针对特定任务，并且因为都是专有数据源、传感器、处理逻辑等，强行把他们说是物联网落地也有些噱头之嫌，毕竟此类系统并不需要接纳其他设备或应用。关于这一部分的看法将放在后续细说。

关于物联网的阶段

我心目中的物联网发展可以划分为3个阶段：

1. 网格阶段 - 万物互联的基础技术实现
1. 设备全互通。即在网络中实现任意消费者能间接接收到任意生产者的数据。
1. 例如将所有传感器进行可视化
2. 任意数据通路中可扩展处理者。即在生产者与消费者之间添加新逻辑。
1. 例如通过计算机视觉分析图像，或自然语言处理分析语音或文字。
2. 平面阶段 - 物联网平台实现与异构数据分析技术落地
1. 处理者可同时接收来自任意生产者或其他处理者的数据，不再限于消费者与生产者的通路之间。
1. 例如分析场景中的所有摄像头，以判断人或各种载具的行为与路线。
2. 例如同时分析来自不同传感器的数据，综合判断场景内设备的运行状态。
2. 生产者与消费者可被自由添加或移除，并动态升级或降级物联网中正在运行的业务。
1. 例如添加或移除摄像头仅影响综合判断的覆盖面与准确度，不干涉或中断系统的运转。
3. 立体阶段 - 稳固的物联网地基赋予社会全感知与公共算力，并将承载海量应用
1. 物联网全国或全球覆盖。即全网任一消费者可获取任一生产者的数据。
2. 大多数数据生产者与处理者装置下沉为密集的社会基础建设。
1. 例如以城市为单位统一优化传感器分布，根据场景需求动态调配。
2. 例如各类载具可以实时获取周边详细公共数据。
3. 算力作为公共资源，同样由社会进行全局优化与分配。
3. 大多数数据消费者无需处理器单元。即转换为纯“前端”装置。
1. 例如手机仅负责触屏交互与显示，实际的数据处理依托在公共设施中。
4. 物联网应用全面覆盖日常与工业，物联网应用的使用、调整与设计成为普通人日常技能。
1. 例如训练面向个人的生活与工作私人助手。
2. 例如训练机器人执行体力劳动任务。

当前我认为处于1到2的过渡阶段，但我个人也无法接触到最尖端的物联网技术，乐观估计个别机构可能在2阶段已初有成效。仅从我所知的、目前已开源的技术来讲，完整实现1阶段已没有任何阻碍，更多问题可能来自于非技术的层面。

物联网第一阶段 - 网格

“人工智能”的泡沫破裂后，最近人们也开始将矛头指向了物联网，骗投资、噱头、无用论的说法接踵而来。某种程度上这些说法也并不算错，因为当下物联网的阶段仍是技术积累与平台建设，很难诞生出惊艳的成果，就好似看着地基和地上一堆钢筋水泥问“大楼在哪”一样。但话又说回来，建设物联网如果只是为了完成某些特定业务，个人感觉基本也不会有太大的前途，毕竟物联网的理念首先就是接入万物，这从初衷上就背道而驰了。

综前所述，为了给未来的物联网发展铺路，我认为当前阶段两点最为关键：一是统一实体封装，例如通过物模型等方案标准化任意实体的属性、方法、事件等接口，使其可被物联网内任意模块所驱动或被驱动。二是统一数据通路，例如通过MQ（消息队列）等手段实现任意设备间的数据通信；当这两个条件满足时，便可通过规则引擎（搭载于处理者实体中）等方式向物联网内注入逻辑，在其成熟后即步入第二阶段。

关于物模型的设计我不久前制作了一个视频，主要的想法都在其中就不赘述了：

对于数据通路的选择就更广了，但数据总线应当是刚需，因为同一条数据须允许被全网潜在订阅。更多需要关注的可能是针对性能与带宽上的优化，例如密集数据（视频流）用MQTT推送必然不太合适，于是问题又重新回到了“应用层协议”上。总之，这些最终都会隐藏于框架之下，对于搭载在物联网平台的实体而言，他们之间的数据通路应该是简单直观且通行无阻的。

在实现“点”（实体封装）与“线”（数据通路）后，需要进一步注入逻辑以实现业务需求，对此需要实现规则引擎。规则引擎实际是个很抽象的说法，更直白点说就是一些可以输入数据、输出数据的服务。然而数据形态千差万别，有稀疏有密集，也可能因其时序性导致服务需要带有状态。规范此类服务要远困难于标准化实体或数据通路，比如实现PLC中通过开关量控制设备的逻辑和计算机视觉中用深度学习模型识别图像的逻辑几乎没有共通之处。所以我认为统一用特定编程语言（比如JAVA）开发规则引擎，或用特定语言（例如SQL）创建逻辑都是不太合理的，在不久的将来会很难覆盖所有的物联网业务需求。

个人认为比较合理的方式是在多语言下开发SDK和脚手架，内置接入物联网平台指令、获取实体元信息，订阅数据总线中的数据等功能，最终作为数据处理微服务部署于边缘或云端。这样对于任何逻辑实现会较为自由，例如Modbus协议服务较适用于C++实现；通用的规则引擎需引入协程，所以较适用于Go；机器学习和计算机视觉自然得借助成熟的深度学习框架，包括OpenCV和PyTorch等，必然需要上Python。当然这些都是一家之言，也希望抛砖引玉，共通探讨。

（继续闭门造车一小段时间，未完待续）