物联网技术上面临的基本问题和操作系统设计

对于网络，无非是以下几种，就物联网整体来说，应该是以下多种网络的混合体。

• 中心服务网广域，就是有一个数据和运算中心，执行各种各样的服务，如数据存储、分析、分发、查询等。
• 无中心网广域，任何终端都可以找到另一个终端，而无需通过任何服务器，从安全性角度来讲，它能避开不受信任的服务器，这是未来组网的发展方向之一。
• 固定局域网，例如一个固定位置安装的无线传感器网络，这种网络，往往内部组成一个mesh网，然后通过一个公共出口连接到公网，或者根本就不连接到公网。
• 流动区域网，例如智能交通，汽车到了哪一个路口，就和哪一个路口的信号灯联网；跑到哪条路上，就跟那条路的路灯联网，是否连入公网，并不重要。

连接也包含组网、维持网络连接、设备发现的问题，维持连接在物联网中是一个很重要的问题，为什么呢？因为物联网中有许多低功耗设备，这些设备绝大部 分时间是休眠的，又要省电，又要不丢失连接，需要有点智慧。维持连接一般是用心跳的方式，对低功耗设备，合理的心跳间隔、快速唤醒、快速连接，连接完后快 速返回休眠状态，就非常重要了。操作系统能做啥？只需要支持常见的无线连接如ZigBee、蓝牙、WiFi等，并实现组网，在低功耗上做足文章就可以了。 至于几种连接方式，诸侯争霸最终谁执牛耳，没操作系统什么事，只能隔岸观火、且看风云。

谈到设备区别，就开始出现问题了，网络中的两个设备，你必须能够区别出他们是不同的个体，就像人的身份证号一样，每个设备也必须有一个身份证号，或 者在你所在的区域网中有一个唯一的号码也行。这个唯一的号码，谁来分配呢，就成了问题，分配号码的人，就成了老大，谁是谁啊，凭什么你当老大？其实设备区 别这个问题，很早就有人想解决了，IPV4有一个32位地址，当时觉得32位足够大了，网卡考虑的周全些，有48位MAC地址，也不够大。maxim公司 的iButton以及802.15.4，都有一个64位的唯一地址，理论上，64位够用了，但maxim公司是一个企业，自然无法成为老 大；802.15.4绑定了特殊的连接方式，也无法成为老大，WiFi节点、有线网络的MAC节点，都会站出来反对你。那只剩下IPV6了，将来，只要需 要接入网络的物联网节点，都会有一个固定的IPV6号码。但802.15.4的64位地址，802.11n的48位地址也不会消亡，有许多设备根本就不上 广域网，只要在其局域网内有唯一地址就足够了。当然，IPV6也有问题，万物联网时代，一个生产水杯的小工厂，怎么低成本地获得IP呢？又如何收回其IP 呢？如果不收回，垃圾桶里，每天都会有无数的IP，即使128位的IP，也迟早会消耗完的。这个问题，操作系统能做什么？操作系统不需要做多少事，只需要 支持IPV6就可以了。

说到设备识别，头痛的问题，就开始来了，就目前而言，并没有任何一个物联网方案能完美解决设备识别的问题。一个最简单的智能交通系统，要实现这样的 功能，哪个方向有车来，就开哪个方向的绿灯，都有车来，就根据流量智能调整红绿灯周期。问题就来了，你如何判断路上过来的是一辆车，还是一条狗！东西向有 车来，南北向跑来一只狗，绿灯给谁放行？

识别车和狗，还是最基本的识别问题，只是识别物种，还没有要你识别个体呢。识别有两个层次，一是人和物之间的互相识别，当然主要是人识别物，另一个是物和 物之间的识别。由于人的智慧，人会根据许多的参考条件来进行模糊识别，人工智能也可以这样做，但人工智能毕竟无法跟人比，只能在有限条件下，做简单的辅助 识别。物联网不是要有智慧么？要为个体提供专属服务么？做不到识别，一切妄谈。有些朋友会想到，用它的128位IP，或者唯一的MAC地址，不就可以了 么？对不起，地址只能起到区别的作用，是起不到识别作用的，除非你为地球上的每一类物体都进行分类，不同种类的物体，给分配不同的IP段。可行么？拉倒 吧，不说自然界每天都在诞生的新物种，或者新发现的物种，就是在创客之都深圳，创客们每天新设计出来的新奇玩意，你都数不过来。自描述是一个办法，因为绝 大多数的物联网应用，只是要求识别部分类别的物体，回到前面所讲的智能交通，只要所有的汽车，都用一句“I am a car，。。。”来描述，就不会跟跑过来的狗弄混。当然，对于具体应用而言，它不需要识别全地球的智能设备，能够识别跟具体应用相关的设备就行了，可以自 己定义识别规则，这纯粹是应用自己的事，操作系统真的没有太多事做，你只能做些辅助线的工作，例如把物体的身份证号和自描述语句传递给应用程序，仅此而已。

最大的问题是沟通，沟通也分为人和物沟通与物和物之间沟通，就是互相明白对方在说什么。让“物体”说同样的话，互相听懂，这是最困难也最缺乏标准也是不可 能有标准的。如果是物与人之间沟通，就好办多了，举个例子吧，一个智能温控器，显示一个按钮，无论在按钮上显示向上箭头，还是三角符号，或者英文 “up”，或者中文“上”，人一看，都能知道这是控制温度上升用的。但机器不行，你必须转化为编码，像“03”表示温度上升，“04”表示下降，其他厂家 生产的主控设备，如何知道“03”而不是“08”表示上升，如何让所有厂家生产的温控器也用“03”表示温度上升，“04”表示下降，这就有很大的问题。 能够用标准去统一千万种物联网节点输出的数据和接受的控制信息格式呢吗？你能穷举物联网中数以千万计的物体所需要输出的数据和接受的控制命令，一一予以编 号么？即使现有的物体都编号了，新冒出来的物种如何及时编号呢？即使解决了编号问题，还有传输顺序呢？数据包里面如果有温度，有湿度，也有告警信息，这些 东西在数据包里面怎么排列，都能搞出无数种组合出来。所以，根本不可能有标准去规范物联网中万千种物体的状态、测量、控制命令的格式，各智能硬件的生产厂 家，一定是自由飞翔的。事实上，也确实有通过穷举网络中所有需要传输的信息的规范，例如CANOPEN的“对象字典”，每一个CANopen设备里，都存 储了一部字典，其主要构成部分是通用字典，这样的话设备与设备之间就能直接进行对话了。ZigBee协议通过profile和cluster ID编码，来列举部分ZigBee设备常“说”的话，使ZigBee设备之间互相听懂。但这两协议，都没有局限于穷举，都是开放的，CANOPEN允许在 通用字典外，定义个性化字典，ZigBee也没有允许使用非标准定义的profile和cluster。无论是对象字典，还是profile，都只是在极 小的一个领域中穷举，它所规范的信息，与物联网中的信息相比，沧海一栗而已啊。而且标准其实是很不靠谱的，所有标准，都是围绕一个非常小的领域进行，尚且 无法避免人们阅读标准后的不同理解，不同理解导致的是不同的执行结果。变电站自动化，这么小的一个领域，有严谨规范的协议，全国只有几十个厂家，而且在国家电网的强力推动下，花了不下几十亿，几年时间，做过无数次互操作测试，才基本统一了设备间传输的信息格式，设备之间才勉强可以对话。

如果能解决设备识别和设备间“沟通”问题，那么智能设备间的互操作就水到渠成了，由于在“识别”和“沟通”方面，无法形成一个开放的、广泛适用的标 准，许多物联网系统就另辟蹊径，尽可能绕过标准问题。同时提供智能硬件开发平台以及通用操作系统的中间件，或者开发一个跨界系统，使物联网中不同设备上使 用相同的开发工具，例如liteOS，就提供了iOS和Android上的中间件，我则直接把操作系统设计成既适用于通用设备，又可以在智能硬件上跑。人 与物之间的操作问题，可以通过远程终端的方案，完美地解决。传统的非智能设备，人和物直接的操作，是通过文字、图形、按键、触屏这些介质来完成的，在物联 网世界里，无非是操作介质和执行操作的智能硬件之间，隔了个空间距离而已。手持的操作界面，就是一个显示和操作终端而已，所有操作，对于设备来说，就像在 设备上直接操作一样，这样才能规避没有标准的实事。例如空调的控制命令，你就告诉空调，用户按了向下的箭头就好了，空调自己知道那是要降温。但如果手机把 遥控命令翻译成命令码下发的话，因为没有标准，每家的命令码都不一样，怎么办？这不是踏进没有标准的泥潭了么？下面我们来谈一种不靠谱但广泛使用的方案， 和两种比较靠谱的方案。

先谈谈不靠谱的方案，现在有些智能硬件厂家，开发专门的APP让用户操作智能硬件，这是死路一条，为什么呢？就以智能家居为例吧，假设家里安装了海 尔的智能冰箱，美的的智能微波炉，西门子的智能热水器，创维的智能电视，格力的智能空调，还有各种智能开关，温度、湿度传感器等等。你的手机要为每个智能 设备安装一个APP，密密麻麻摆满你的手机，那些密集恐惧症的患者，非跳楼不可。所以，需要安装厂家专门开发的APP才能操作的物联网方案，都是不靠谱的。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友