订阅移动开发RSS CSDN首页> 移动开发

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

发表于2015-05-28 13:41| 次阅读| 来源CSDN| 0 条评论| 作者Garry Xin

摘要:本文转自CSDN博客。作者在电信行业从业多年,目前正在推广一款开源物联网系统。他认为物联网操作系统需要同时满足软硬件分离和解决碎片化两个问题。同时,他还对目前业界结盟状态、华为Lite OS、腾讯TOS等做了分析。

在周末的上午,坐在五道口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),以供讨论之用。

原文来源:CSDN博客

0
0