IT 云与物联网云的比较-Atmel 公司

在2013年年中的时候，一个神奇的词汇“物联网”，也被简称为“IoT”，让整个的 IT 世界都为之癫狂起来。而作为这种狂热情绪的直接结果，一大批原本针对完全不同的终端用户而开发出来的产品却在一夜之间就将其市场宣传产品“改弦易辙”，以物联网产品的新形象闪亮登场。企业竞相在每一位高管或者每一款小产品的名称前都冠以“物联网”三个字，竭尽全力让自己能够跻身于物联网的队伍当中并成为其生态系统的一部分。新举办的各类展览纷纷宣称自己在物联网行业拥有权威地位，天使投资人和风投机构蜂拥而至，为物联网注入资金，催生出各种不可思议的创新思维，有时甚至让我想起了上世纪九十年代末的网络泡沫以及 Lemonade.com 网站受到资助的情景。新的标准体系也围绕着物联网设备的提供而建立起来。好像就是一眨眼的功夫，IT 领域的大部分人都突然变成了物联网专家。

IT 云与物联网云的比较 - 没有一个万能的解决方案

在这个过程中云企业自然也毫不例外。虽然云的整个物理架构并没有改变，但是针对企业 IT 管理和移动应用程序支持而开发的平台和软件都成为了平台即服务 (PaaS)、软件即服务(SaaS)物联网平台，且都宣称自己“可满足物联网要求”。在 2013 年末于巴塞罗那召开的一次物联网国际会议上，不仅每位主旨发言者都大谈基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)所构成的“金字塔隐喻”，而且拜物联网所赐，几乎每位主旨发言者都谈到了“一切即服务(EaaS)”。

在如此的大肆宣传和鼓噪之下，现实与虚构之间的界限就很难分清了，除非你能够认真研究，而且必须是非常深入的研究才行。这种模糊不清是由物联网的宽度以及物联网所包含的众多垂直市场所造成的，其范围甚至可以涵盖我们目前所知的生活的方方面面。而每个垂直市场都有自己独有的“物”，所以从设备的角度来看并没有一个可以解决所有问题的万能方法。为了能够支持这一广泛的领域，电子和软件基础设施都必须具备不同的标准和传输层次。让情况变得更为复杂的是，IT 行业的许多重量级企业都把物联网视为一个转折点，让他们可以借此机会进行转型并进入其他的业务领域。因此，这些大企业的着眼点是他们目前已有的资产，并在此基础上对物联网所需要的基础设施进行定义，而不是以是否合乎逻辑、技术上是否合理作为定义的基础。那些从未涉及数据中心软硬件业务的企业，自然会公开提倡将大部分的数据处理工作放在网络的其他地方实施(“更靠近来源”)，其他一些企业则支持与此相反的方法，同时第三股力量却主张大部分的处理工作应该直接由客户设施内智能网关平台的各个层级以及除上述两个方面之外的其余部分予以完成。同样的矛盾观点也出现在了无线通信协议、网关、对于“物”的定义、服务实现方案等诸多方面。

一个很好的例子是行业内最大的企业之一目前正在着力进行的宣传。他们把物联网称为“一次处于常开状态的革命”，从边缘结点/传感器结点(即从物的一侧)收集到的数据“每时每刻”都在向云端传送。这种方式需要具备极大的带宽以及强大的存储能力用以从云端收集数据，还需要进一步提高其被动式大数据分析能力以处理来自云端的如此海量的数据。很明显，他们所要销售的是锤子，所以就把世界上的所有事物都视为钉子。而真实的情况是，物联网是一个“在大部分时间都处于关闭状态”的系统，其所产生的数据比他们的描述要少得多，而且很少会有数据能够最终到达云端。举几个例子：

1. 一扇门或者一把锁大部分时间都是处在休眠状态，直到传感器在开门或者接近门锁的过程中触发了一个唤醒指令，才会将几个字节的数据传送到网关，然后重新回到休眠状态。

2. 桥梁上的温度传感器会每隔一段时间就从休眠中醒来一次，将温度的变化情况及时通报给路边的网关，同时告知桥梁是否结冰，是否需要通知交通部门派除冰车过来以避免交通事故的发生。

3. 在美国德州，安装在写字楼空调上的震动传感器会每两个小时监测一次空调压缩机运行的声音。如果压缩机的声音中有迹象表明，这台空调有可能会在几周之内出现故障，那么传感器就会马上给大楼物业发出信息，让其派一位技术人员排除潜在的故障，以避免在火热的七月空调突然停止工作。

4. 在拖挂卡车所运送的水果集装箱里，乙烯气体(水果和植物成熟时所散发出的植物激素)探测仪每隔30分钟醒来一次，将集装箱内的数据传送给卡车驾驶室内的网关。通过这些数据可以预测出水果的腐烂速度，让司机可以在必要的情况下将运输目的地临时更改为就近的城市，从而让水果可以有更长的保质期，或者将水果直接送到果酱加工厂，避免水果出现腐烂的同时还浪费了卡车的燃料。

在上面所提到的每一种情况中，以及与此类似的其他情况中，“物”(即水果集装箱、空调、桥梁、门锁等)的大部分时间都是处在休眠状态，只有在某个事件的触发下或者在预先设定的时间间隔内才会苏醒一次。只有通过这种手段才能够让这些设备仅仅依靠电池就可以运行长达数年的时间。到底需要多少字节的数据(而不是兆比特每秒或者千字节每秒)报告这些事件呢?所有的这些事件是否都值得发送到云端?实际上，在本地网关运行的本地事件处理和分析引擎将会决定什么内容需要发送到云端，只有在出现例外事件时(门开了、水果变质了、压缩机出现故障、桥梁出现结冰)信息才会立即传送到云端。除此之外，只要一切都处于正常状态(处在预先设定的允许范围之内)，数据就会按照预先设定的时间间隔(如如每24小时一次)进行记录且元数据将会上传至云端。即使涉及到视频图像的采集，所需要的带宽也不会超过 2 Mbps(兆比特每秒)。

根据我对多个拥有大量建筑的大型企业校园的分析结果，物联网服务在不提供视频功能的情况下，总计只需要15Mbps 的最大带宽就可以完全支持这种类型的物联网在提供服务的过程中与云端之间的通信。所以对于那些鼓吹所有的应用和所有的“物”都保持常开状态、因而需要大量带宽资源的人，我们应该持怀疑态度。他们将物联网做这类描述的目的何在? 当然了，如果我们所考虑的企业校园到处布满了智能设备，人们随时都在利用“对话频繁和持久的通信手段”传输大量的数据，那么你肯定需要比 15Mbps 要多得多的资源与云端保持连接。是不是这些人将 IT 基础设施与物联网基础设施混为一谈了?

为了全面实施物联网，就必须要采用系统层次的方法，以覆盖从最细小的边缘/传感器节点(物)、各种不同类型的网关、一直到云端和数据中心、各种应用以及服务供应商等各个方面。这其中包括嵌入在现场设备或云端的数据分析引擎，带有各种不同种类的 SKD 和通信智能体、数据缓存、各种不同层和不同级的带宽管理等各方面工作。而全世界有能力将所有上述各项能力都集于一身的企业则是屈指可数的(只能达到一位数)。即使能够具备这种能力，企业依然需要与小设备/ 物一侧的企业结成合作伙伴。因此，当某个人声称他们可以提供一站式服务的时候，实际情况是：他们或者能够支持某种现有的物联网基础设施与云之间的通信并为其增加某种新的特性(大部分物联网垂直市场的某种子设备)，或者他们的系统并不如他们所说的那样全面，甚至是这两种情况都存在。

更不用说，在目前这个阶段我们所能选择的无一例外地都是各自独立的云和各自独立的物联网系统。虽然某些公司已经开始开发一种云生态系统(即所有云的云)，但是在成为真正的物联网云生态系统之前，他们还有很长的一段路要走。

IT 云生态系统(与物联网云生态系统相对应)在过去几年当中已经走过了一段发展之路。正如最初所预期的那样，胜利的曙光已经开始出现，随着技术的不断推广，一个无缝的和无限的虚拟环境已经出现，在这个环境中，通信、存储、计算、网络和移动服务、分析、以及其他的商业目的都可以得到实现。随着需要先期资本支出的项目极大地减少或者消失，云的收益模式已经开始结出成果。这其中包括用户可扩展性变得更加灵活和可控，不同企业可以按照需求自行增加功能，以及由此而带来的即付即用的好处等。云服务提供商承担起了许多企业对于 IT 方面的要求，已经成为他们至关重要的商业和渠道合作伙伴。

IT 云与物联网云的比较

虽然有了上述的种种成就，我们的根本问题依然是：传统的 IT 云及其生态系统与物联网云及其生态系统是否是一样的?

答案是：虽然有60%到70%是一样的，但是另外30%到40%的差异会让你推出的物联网产品铩羽而归，让看上去似乎是为物联网准备的云对你的应用几乎毫无用处。

这种差异几乎存在于整个的端到端系统当中，从“物”的一侧一直到云端的数据中心都无一例外。传统的 IT 云、网络或者移动应用云通常代表着较大的设备和较为丰富的云资源。在过去的几年里，传统云系统中的“物”通常都由计算机、自动售货机、汽车、在客户设施内的网关、或者是智能终端(笔记本电脑、平板电脑、智能手机等)所组成。这些设备通常都是通过直接的蜂窝连接、蜂窝(WAN)+Wi-Fi(LAN)、或光纤(WAN)+ Wi-Fi(LAN)与云连接在一起。而新一代物联网中的“物”则更多是资源极为有限的设备，例如安装在门廊处的传感器一般都是通过小型电池驱动，用于探测通过后门进入房间的人，还有安装在道路设施(桥梁等)上并通过电池驱动的震动传感器，以及在之前列出的几个例子中的设备等。传统的情景是在一间办公室里有20台智能终端，这些设备或者通过墙上的电源插座提供电源，或者通过较大的电池提供电力且电池会定期地进行充电，而物联网云及其生态系统的情景就是在这样的一间办公室里有500 种不同类型的传感器和“物”，如果有多间办公室的话物的数量会多达1000个，且他们中的大多数都是在电池的驱动下工作长达数年的时间(消费级别的物联网电池寿命为4到5年，工业物联网的电池寿命为8到12年)。其中的一些物上安装一台小型的8位微控制器作为其大脑，具有极为有限的内存和其他资源，也许还需要安装在好几层的网关、继电器、开关、甚至是其他的“物”之后，位于一个处于休眠状态的网络里。当通信连接开启时(要记住大部分时间内这些微控制器都处于不工作状态)，带宽非常窄，信息可能会在网络中通过几次传递。对于那种“对话频繁”、定期向物发出 ping 指令模式的通信系统来说，这样的要求肯定是极难满足的。

极为重要的一点是，一个系统必须要能够进行全面的扩展和升级，而且这种扩展不仅仅在云一侧，而且在云到物之间的连接一侧 - 最终在物的一侧 - 都应该是可行的。除了安全的通信系统之外，数据的采集和收集能力同样也必须是可扩展的。如果你的目标是消费应用程序，那么最基本的要求之一就是必须要有一个可靠的移动应用开发平台，且平台必须能够支持最常用的智能手机操作系统。也就是说，你必须要让中间件变得更加灵活、可扩展、能够同时管理更多的物。另外，还需要对过去的整个通信拓扑进行反思。最后，要对分析引擎和应用开发环境给予更多的关注，根据你所要开发的物联网应用程序的不同，可能需要完全不同的视觉呈现工具和商业模式。

下面是 IT 云供应商向物联网云供应商转型时需要考虑的几大要素：

· 理解你的目标垂直市场，为这个市场提供一站式服务。在物联网中并没有一个可以解决所有问题的万能方法。要了解某个垂直市场，就要考虑这个市场的变迁过程以及未来的商业模式。例如，如果你的目标是随时随地追踪医院里的人员及其具体位置，那么可能会需要使用带有生物计量传感器的可穿戴设备，而且这些人的生命体征数据同样也需要得到监测。可以预见的是，你的服务同样可以覆盖对生物计量传感器的追踪，而这些传感器通常都是由电池驱动的小型设备，可提供的带宽也都是最小的。在这种情况下，一方面与一个平台即服务 (PaaS)或软件即服务(SaaS)提供商合作管理其位于同一区域的设备，另一方面与另外一个云服务提供商合作管理另外一套独立的设备，这种方案根本就不在可选范围之内。因为需要考虑的问题包括通信协议、网络、带宽管理、以及物联网云架构需要支持的传输技术等各个方面。

· 可扩展的数据分析以及事件处理引擎都是必需具备的，因为物联网的增值作用主要来自于数据分析，而“数据资本”则是差异化的根本所在。在云端以及本地/网关一侧是否具备合适的分析工具引擎?新的内存流媒体技术可以改变我们对数据的处理速度，所以在某些物联网应用中也是必需的。因此传统的数据提取、转换和加载(ETL)模式将让位给准时性(JIT)方法(即实时方式与批处理方式的对比)。你是否有能力管理快速/流媒体数据分析处理过程，以应对那些需要极快的(近乎)实时数据处理能力的物联网应用?例如，在远程医疗保健和老年人监控应用中，位于云端的被动数据处理已经无法满足要求，必须采用在本地智能网关中运行的本地快速数据分析能力才能够应对诸如突发心肌梗塞或家用自动设备失火这样的紧急情况。同样非常重要的一点是，一定要找到一家专门针对某个垂直市场的服务提供商，如果你不是这样的一种服务提供商，那么就找到一家并与其合作，只有这样才能够让你的事件处理和数据分析引擎针对具体的应用案例和商业模式做出精细的调整。如果你的分析引擎只能针对网络内有限范围内的参数提供形象和有效的深入分析，那么一定要与其他的合作伙伴合作以弥补缺失的部分。

· 详细了解需要监测/采集的是什么类型的数据，以及客户需要什么样的分析结果。也就是说，针对具体功能开发出一系列的设备数据模型。不要让自己成为物联网云解决方案中的“万能瑞士军刀”。因为虽然瑞士军刀可以做许多事情，但这并不意味着瑞士军刀能够把所有的事情都做的很好。了解你所要服务的垂直市场(要素1)对本要素的实现同样具有帮助。某些应用中，在利用分析工具和可视化工具对数据进行处理之前，首先需要通过外部的分类算法和富集工具对数据进行组合。这个过程可以极大地提高数据使用的效率和方便程度(例如在打井之前必须要首先了解水网管线的位置，在为货物重新确定路径之前需要了解其他集散中心的位置等)。

· 开发一个完全模块化的端到端系统。因为大部分的大型原始设备制造商可能已经有了自主品牌的云服务，他们所需要的只不过是你所提供服务中的一部分内容。所以要提供界定明晰的 API，以及对防火墙友好的具有适应能力的连接架构，并且要熟练地使用客户的基础设施、分析工具引擎、应用程序、视觉化工具等。客户感兴趣的也许只是你的通信系统，或者仅仅需要功能上的某种结合。你的方法越灵活，就越能够更好的让自己的产品满足客户的需求。在云的一侧，云生态系统的形成(即所有云的云 - 服务器与其他服务器的通信)就是下一个需要完成的任务。一个强大的生态系统是物联网云管理的核心所在。

上文中提到的模块化系统也许意味着为你的商业模式建立一种分层的定价方法。灵活性应该不仅仅存在于你的技术产品之中，所以应该对新的商业模式持开放的态度。

· 在新的服务提供架构之后应该跟随有大的生态系统，例如开放互联联盟(OIC)等。在消费级和工业级物联网领域，标准化将最终占据主导地位。尽管由各种字母符号的简称所组成的通信协议(例如MQTT、XMPP、DDS、AMQP、 CoAP、RESTful HTTP等)可能会继续发展，标准化也同样处在进行当中并可以为你提供清晰的视角。为了达到“对症下药”的目的，各种标准正在制定当中。要做好升级的思想准备，因为你今天的专有系统也许在将来的某一天会需要向标准系统升级，如果不这么做的话你就会与整个的生态系统相脱离。有了这样的思想准备，你的系统就应该在今天提供相应的对策。

· 培养在无线通信领域的专业技能(蜂窝、WiFi、BLE、802.15.4/Zigbee、6LowPan、subGig、SigFox等)，或者与具备此项技能的一方合作。许多 IT 云企业在这方面都存在很大的缺陷，需要寻找一个合适的合作伙伴来优化他们的 IT 云，使其能够支持上述复杂的无线通信协议。他们同样需要在无线连接的类型以及有限带宽的基础上对系统进行优化。对于应用开发方的人员来说这一点同样有效，因为对于物联网来说这样的定制化工作是必须要实施的，而且通常对于蜂窝技术行得通的方案，挪到 WiFi 或 BLE 或 Zigbee 上未必也会行得通。当所设定的目标是某个垂直市场时，这一点尤其显得重要，因为不同的垂直市场需要的也许是不同的无线通信协议，甚至同时需要多个无线通信协议，所以会遇到不同协议共存所带来的问题。一个了解你的物联网云要求的半导体合作伙伴可以从无线通信和带宽管理的角度帮助你优化系统。

· 无论你拥有自己的 SDK还是采用了基于智能体的机制，都要搭建一个轻量级的通信系统。典型的 SKD 虽然让移动应用程序的开发和管理变得更加方便，但是不要忘了，与那些负责向物联网系统传递数据的细小且资源有限的传感器相比，智能手机所拥有的资源显然要大得多。轻量级的 SDK 或基于智能体的系统具有更高的可预测性，也更加容易与内存有限或者通过电池驱动的设备整合在一起。轻量级智能体可以降低设备的复杂程度和成本，可以根据他们在系统中所处的位置以渐进的方式不断增加自己的能力。很明显，系统中在物的一侧增加的“花里胡哨的东西”(即追踪或警示状态的统计数据的数量)越多，SDK 或智能体所留下的印迹就会越大。随着你逐渐上升到网关的层级并有越来越多类型的机制、功能、传感器、通信和警报需要监测，智能体或者 SDK 的规模就会增加。确实没有一种方案是万能的，但是在应用和数据管理方面永远保持节俭的态度一定是有效的。到目前为止，根据我与各种物联网云生态系统合作伙伴的合作经验，SDK 和智能体在内存中的印迹大小从3K 到150 K 不等。物联网云的发展之旅已经开始，我坚信在不远的将来更为高端的方案(以及一些中间步骤)将会减少，而缓存机制将会越来越壮大。

另外，要部署一种以具体环境为中心的带宽管理系统，因为这样的系统不会仅仅因为你的管理层面的活动就贪婪地将整个带宽都据为己有。经验告诉我们，在与中间代理和缓存功能的通信连接中，所占据的带宽不要超过15%。

· 关注“物”，重点放在方便使用上。也就是说，提供的设备要便于使用，让即使是一个物联网开发的新手也能够按照步骤自己完成相应的工作，无论采用何种传输技术或可用资源是多少。如果所花的时间太长、错误多多、或者需要大量的开发人员针对某个具体的架构对智能体进行调整、定制/优化，那么你的目标市场就只能剩下那些大型的原始设备制造商了。如果你选择与软件服务企业合作，那么这种合作虽然可以让你进行更好的升级并获得额外的带宽，但是代价是提高了成本。这样一来你的目标市场也只能是那些有支付能力以获得你所提供服务的企业。与其如此，倒不如从一开始就让整个过程变得极为容易，从而可以最大限度地覆盖潜在的用户。也就是说，从物/传感器 API 的编写，到本地网关和云网关，再到智能体和通信以及服务 API 的编程，无一不将重点放在简单、易用，放在为你的客户/开发人员带来开箱即用的体验上面。

· 关注系统中各个组成部分的可视化工具和用户体验。“物的虚拟化和可视化”(包括那些简洁而强大的应用程序，将设备数据模型转化为云中可以理解的信息)是一个很大的价值命题。如果你的目标是消费级物联网垂直市场，且智能手机在其中占据了非常重要的地位，那么你所提供的服务中应该包括一个强大的移动应用程序开发环境。IT 云和物联网云都有各自不同的数据消费人群，具备出色的可视化特性可以让你走在竞争对手的前面。

· 最后，也是非常重要的一点，你是否具有一个强大且牢固的安全和认证机制，且采用非常先进的加密算法?是否支持 ECC 和 AES-128/256?是否拥有以 PUF 为基础的密钥生成机制?物联网领域存在着极高的风险，需要在系统的安全上花费更多的精力，从最细小的拥有有限资源的物一直到云端，方方面面都需要考虑到。需要注意的一点是，在物联网应用开发人员当中对安全知识的了解目前依然不高，云合作伙伴需要具备相应的能力，并贯彻和实施最佳实践。在物一侧需要保护的基本要素包括安全引导、物的身份认证、信息加密和完整性、以及可靠的密钥管理和存储流程。一个了解你的物联网云要求的半导体合作伙伴可以从“物”的安全角度帮助你优化系统。

从 IT 云向物联网云的过渡已经开始，正如 IT 云的发展是一个漫长的旅途一样，为了支持物联网应用而进行的转型同样是一个漫长的旅途。面对这种变化，最好的应对方法是什么?让转变成为一个涵盖范围广泛的过程，因为只有这样才能够随着市场的不断向前发展让你的物联网云保持可持续的发展。

点击阅读英文原文