在周末的上午，坐在五道口Starbucks咖啡厅里，慢慢啜着稍带苦涩的冰美式，嚼着偶尔从吸管里吸上来的焦糖粒，目光停留在玻璃窗外来回穿梭的车辆上，心绪散漫…很久没有这么悠闲和放松了。记得第一次喝星巴克的美式(Americano)咖啡，貌似是2004年，在中东的巴林做项目，跟客户交流的时候。当时也是周末，交流地点就定在一个星巴克咖啡厅里。有两个客户，名字都很阿拉伯化，一个叫做Ahmad(貌似翻译为艾哈迈德)，另外一个叫做Mohamod(莫哈默德)，分别是巴林电信的CTO和副总裁。当时交流的内容，是如何把客户基于电路交换的电话网(PSTN)，演进为基于IP承载的NGN。十年过去了，现在貌似还是做着同样性质的工作，不过内容变了，是如何把客户的IP网络，演进为SDN。

本文的主题仍然是物联网操作系统，上面的内容纯粹是作为引子，与本文后面的内容没有任何逻辑关系。如果非要找出一点联系的话，那么只能是哲学层面的联系了，那就是任何事情都在变化和演进，永不休止。物联网领域也是这样，虽然至今未成气候，但是其架构演进的速度，或者说“折腾”的速度，一点也不比电信网络慢。最初的时候，物联网被定义为三层架构，即所谓的传感层，网络层，后台支撑层。很多公司或组织，按照这种结构推出了产品，比如爱立信，推出了基于其核心网平台的EDCP(貌似是爱立信设备连接平台)，无限制放大网络层的功能要求，因为这是其客户-电信运营商关注的领域。很多电信运营商，也被设备商忽悠，投资建设了遵循这三层架构的物联网平台，结果亏得一沓糊涂。后来，物联网公司，比如BAT等，发现物联网是一个潜在的市场空间，于是切入进来，按照互联网思维来做物联网，于是物联网又被这些互联网巨头定义为两层，即终端层和平台层。其中终端设备直接与平台层链接，弱化了原来架构中的“网络层”。在这种结构下，互联网公司提供平台服务，这样就面临一个问题，如何让海量的，种类各不相同的终端，接入到互联网公司的平台呢?在没有标准可以遵循的情况下，只有两条途径，一条是把平台做得足够大足够好，形成事实标准，形成垄断效应。但是物联网行业是发展初期，很难形成这样一家独大的平台，于是就只能采取第二个途径-结盟，说白了就是平台厂商和终端厂商联合起来，定义一个私有的标准，然后自己玩。最普遍的表现，就是互联网公司与家电厂商结盟，比如小米和格力，海尔与阿里，等等。结盟模式是最不利于行业发展的，尤其是在行业发展的初期。结盟的结果，是形成了一个个小的，封闭的领域，因为联盟之间的标准不同，相互之间不能交互，其结果可想而知。

在电信行业混了这么多年，深知这个行业的诸多弊端会严重阻碍物联网的发展，因此我个人更倾向于互联网公司来做物联网。但互联网公司采用结盟的方式，却是非常不合适的。为了克服结盟的弊端，必须在终端和平台之间，插入一个”中间层“，把这种强耦合关系打破。这个中间层，就是物联网操作系统。

物联网操作系统的概念，是与电信行业的几个同仁交流后提出的，起初的目的，并不是解决互联网与终端厂商结盟的问题，而是站在运营商的角度上，试图解决运营商网络在物联网领域面临的挑战。一个典型的场景，就是智能抄表解决方案中可能导致的无线网络信令风暴。考虑一个安装了百万电表级别的城市，所有电表通过运营商的无线网络连接到抄表平台。在月底的时候，同时上报抄表数据，这时候大量电表同时产生的无线信令，会把运营商网络搞垮。于是希望在终端层面，嵌入运营商提供的操作系统，操作系统中内嵌定制化的网络访问规则，把并发的大批量的网络访问，变成平缓的分散访问。

后来随着与更多的业内人士交流和碰撞，对物联网操作系统的概念做了进一步的思考之后，重新定位为解决上面描述的结盟问题。在2014年的一篇文章中，对如何解决结盟问题，以及物联网操作系统的整体框架，做了详细描述。这个定位和框架，引起很多业内人士的共鸣，大部分持认同态度。

具体来说，在缺乏标准的情况下，要打破结盟的有效措施，就是软硬件分离。终端厂商只聚焦终端功能的开发，这是他们的强项。把终端功能通过操作系统API的形式暴露出来，提供给软件APP调用。比如一个智能开关，只要通过API，提供开关打开，关闭，调节电量，网络连接等功能。具体什么时候打开，与其它家电设施如何联动，如何形成有价值的智慧家庭解决方案，则是智能家电平台厂商要做的工作。平台厂商开发运行在智能开关上的应用程序(APP)，调用智能开关提供的API，实现智慧家庭功能。由于具体的通信协议和业务逻辑，是由平台厂商自己实现的，因此就不存在强绑定的问题。智能开关的用户，可以通过更换APP的形式，来更换智慧家庭服务提供商。这种模式与智能手机是一致的，可以通过安装或卸载APP，来灵活选择电子商务提供商。但是物联网终端与PC不同，不像PC这么标准，有固定的架构和指令系统，物联网终端的架构多种多样，CPU更是千变万化。为了确保同一款APP能够应用在多种多样的硬件上，必须采用硬件无关语言来编写APP。比如Java，比如Python。当前HelloX操作系统采用的是Java语言。

物联网的另外一个特征-碎片化，也是物联网操作系统必须要解决的。所谓碎片化，是指物联网终端的硬件配置各种各样，比如内存配置，从只有十几K甚至几K内存，到数十M或数百M。再比如外围设备，有的仅仅具备简单的传感和网络功能，而复杂一点的终端，则具备完善的Ethernet或LTE连接支持。碎片化会导致企业开发成本的剧增，因为你必须为一些终端选择低端的操作系统，为另外一些终端选择相对高端的操作系统。这些操作系统提供的工作机制和API都是不同的，这样就会导致企业无法共享开发和维护经验，无法共享代码和人力。物联网操作系统必须要解决这个问题。目前来说，可能的解决方案，就是可裁剪性。同一个操作系统，通过裁剪或动态配置，既能够适应低端的需求，又能够满足高端复杂的需求，而共享相同的工作机制和API，以及开发工具。

在满足上述两个条件的前提下，物联网操作系统还必须能够支撑物联网的另外一个重要特征-本地协同。举例来说，智能开关应该可以与智能电视协同，在智能电视被关闭后，应该能够通知智能开关，以切断电源，节约电量。这包含了本地设备发现，能力交互，工作协同等几个相互关联的要素。很多协议或标准可以支撑这种操作，比如AllSeen联盟搞的AllJoyn标准等。物联网操作系统可以自己定义相关交互规则，也可以直接集成AllJoyn等。总之相对上述两个特征，支撑本地协同要简单得多。

说了这么多，就是试图对物联网操作系统做一个定义。并不是所有的操作系统都是物联网操作系统，只有满足上述三个特点，即能够支持软硬件分离，支持碎片化特征，支持本地协同的操作系统，才算是物联网操作系统。这只是个人的理解，不同意见的朋友，可以探讨交流。只有本着开放合作的态度，找到最大公约数，然后逐步扩大这个最大公约数，才能慢慢的把一个行业做好。需要注意的是，这里强调的是“开放合作“，而不一定非要”合作共赢“。经济学中有一个著名的概念，叫做”帕累托改进“，是指在参与经济活动中的多个player之间，任何一个player经济利益的扩大，只要不会导致其它player的利益降低，都叫做帕累托改进。因为这种改进，会导致整体经济效益的改进。在物联网领域的合作，我们也建议遵循帕累托改进的原则。另外一个观点就是，物联网操作系统必须是中立的，即不倾向于支持任何厂商的终端，也不倾向于支持任何厂商的物联网后台系统。同时，物联网操作系统必须要开源，以展示开放和中立。

物联网操作系统的概念似乎得到了越来越多的认同。这几天，华为在一个SDN大会上，发布了叫做LiteOS的物联网操作系统，主要支持自有的芯片和物联网终端，并内置私有的协议，与自产的物联网网关进行配合。实际上，在2014年的行业分析师大会上，华为就公布了开发物联网操作系统的想法。但是如果用我们上面定义的三个特征来匹配，就会发现华为发布的操作系统，不满足上述全部特征。首先，从目前能够拿到的信息来看，LiteOS并不能支持软硬件分离，也不能保持中立性，因为其目的，还是希望对自有芯片进行更好的支持，同时与自产的物联网网关进行配合，有很强的倾向性。虽然宣称要开源，但是至今尚未看到其源代码。实际上，我个人是很期望华为能够发布一款真正的物联网操作系统的。依托操作系统，建立一个完整的产业链，从而促进行业的发展。依华为的实力和品牌，完全可以做到这一点。但是对LiteOS的发布，却有一些失望的情绪，首先其名字，就不太合适。物联网操作系统可不能仅仅是Lite，而应该能大能小，小可以Lite，大则可能比通用操作系统还要复杂。但LiteOS未来的发展如何，目前下结论显然太早，还需要长时间的观望。个人仍然期望LiteOS能够真正发展起来，改变笔者对Lite长期以来形成的贬义印象。

另据国外媒体报道，Google也将在近期的I/O大会上，发布一款物联网操作系统Brillo。刚看到这则新闻，我心中的冲击是很大的，显然，Google认识到了Android不能适应物联网的需求，终于另起炉灶了。但是看到报道中描述的细节，Brillo还是依托Android的内核开发，能够适应32M到64M的内存要求，我个人又失望了。显然，依托Android框架，采用Java语言实现软硬件分离，完全满足物联网操作系统支持软硬件分离的特征。但是却不能支持碎片化特征，显然32M以上的内存要求，就把绝大多数物联网终端排除在外了。因此，个人不认为Brillo能够像Android一样，一统物联网领域。但结果如何，还是需要实际表现来说明。

另外，腾讯也发布了用于物联网领域的操作系统TOS，但是其内核，仍然是基于Android，还不如Brillo。还有一些其它的物联网操作系统，就不一一评论了，朋友们可参照上面的讨论，自行印证一下。

最后，还是要说一下HelloX项目。显然，HelloX操作系统是必然满足上述讨论的物联网操作系统的特征的，因为我们就是按照上述特征，来开发HelloX的。对于软硬件分离的支持，HelloX通过移植一个业界广泛使用的嵌入式Java虚拟机JamVM，通过Java语言来实现。这种实现方式，与Android通过Java语言是实现APP与硬件的分离原理是一样的，无需多说。对于支持碎片化特征，HelloX的伸缩性非常强。可以在编译时，裁剪掉不需要的模块，来匹配低端硬件的需求，当前可以裁剪到只需要十几KRAM的级别。显然，这时候是不能支撑Java虚拟机的，在这种低端硬件上，功能往往比较单一，也无需支持Java。对于高端硬件的支持上，HelloX目前可以支持服务器级的硬件，比如，HelloX曾经在Dell PowerEdge级的服务器上运行。另外，HelloX是完全中立的，没有任何硬件的倾向性(也无法倾向，因为我们没有硬件J)，更没有任何平台倾向性。实际上，对任何平台的支持，在HelloX上都表现为一个特定的APP，可以动态安装和卸载。另外，代码完全开源，目前托管在github上(github.com/hellox-project/HelloX_OS)，任何人可以下载和修改。

我们的目标，是开发一个能够支撑物联网产业发展的基础软件平台，来促进产业的发展，提升人们的生活质量。目前HelloX项目还在开发过程中，欢迎有兴趣的同仁参与我们。

最后再澄清一下，本文的内容和观点，仅仅是一家之言，供业界同仁讨论和碰撞。相信我们的目标是一致的，都是为了更好的促进行业的发展，在这个过程中实现自己应有的价值。另，如果希望转载本文，请注明出处和作者，以及联系方式，以供讨论之用。

作者：garryxin

来源：51CTO