对物联网操作系统特征和定位的思考

对物联网操作系统特征和定位的思考

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

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

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

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

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

具体来说,在缺乏标准的情况下,要打破结盟的有效措施,就是软硬件分离。终端厂商只聚焦终端功能的开发,这是他们的强项。把终端功能通过操作系统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项目还在开发过程中,欢迎有兴趣的同仁参与我们。

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

欢迎加入物联网操作系统讨论QQ群,进行讨论和交流:38467832

 

posted on 2015-05-24 13:41  三少爷的剑123  阅读(123)  评论(0编辑  收藏  举报

导航