从IT云迈向物联网云的过渡已经开始。正如IT云的发展一般，物联网应用转型同样是一个漫长旅途，面对全新的系统级设计、多元无线通讯协议、大量资料采集和分析等十种剧烈变化，设计者必须通盘了解物联网云需求并掌握相关半导体软硬体技术才能实现。
在2013年中时，一个神奇的词汇物联网(IoT)，让整个IT世界为之疯狂。而这种狂热情绪的直接结果，大批原本针对完全不同终端用户而开发出来的产品，在一夕之间就将其市场宣传产品改弦易辙，以物联网产品的新形象闪亮登场。企业竞相在每一位高阶主管或每一款小产品的名称前冠以“物联网”三个字，竭尽全力让自己能跻身于物联网队伍当中，并成为其生态系统的一部分。
新举办的各类展览纷纷宣称自己在物联网行业拥有权威地位，天使投资人和风投机构蜂拥而至，为物联网注入资金，催生出各种不可思议的创新思维，有时甚至让笔者想起上世纪90年代末的网路泡沫及Lemonade.com网站受到资助的情景。新标准体系也围绕着物联网设备的提供而建立起来，好像就是一眨眼的功夫，IT领域的大部分人都突然变成物联网专家。
在这个过程中云端服务企业自然也毫不例外，虽然云端的整个物理架构并没有改变，但是针对企业IT管理和移动应用程序支持而开发的平台和软体都成为了平台即服务(PaaS)、软体即服务(SaaS)物联网平台，且都宣称自己可满足物联网要求。
物联网标准和传输层次颠覆传统
在2013年末于巴塞隆那召开的一次物联网国际会议上，不仅每位主旨发言者都大谈基础设施即服务(IaaS)、PaaS、SaaS所构成的“金字塔隐喻”，而且拜物联网所赐，几乎每位发言者都谈到“一切即服务(EaaS)”。
在如此大肆宣传和鼓噪之下，现实与虚构之间的界限很难分清，除非用户认真研究，而且是非常深入的研究才行。这种模糊不清是由物联网的宽度及所包含的众多垂直市场所造成，其范围甚至可涵盖目前所知的生活所有层面;而每个垂直市场都有自己独有的“物”，所以从设备角度来看并没有一个能解决所有问题的万能方法。
为支持这一广泛的领域，电子和软体基础设施都须具备不同的标准和传输层次。让情况变得更为复杂的是，IT行业的许多重量级企业都把物联网视为一个转折点，让他们可藉此机会进行转型并进入其他的业务领域(图1)。因此，这些大企业的着眼点是他们目前已有的资产，并在此基础上对物联网所需要的基础设施进行定义，而不是以是否合乎逻辑、技术上是否合理作为定义的基础。
图1 产业界转向物联网云端生态系统的革命已经展开。
那些从未涉及资料中心软硬体业务的企业，自然会公开提倡将大部分的资料处理工作放在网路的其他地方实施(更靠近来源)，其他一些企业则支持与此相反的方法，同时第三股力量却主张大部分的处理工作应该直接由客户设施内智慧闸道器平台的各个层级及除上述两个方面之外的其余部分予以完成。同样的矛盾观点也出现在无线通讯协议、闸道器、对于物的定义和服务实现方案等诸多方面。
突破设计迷思 物联网数据可比想像的少
一个很好的例子是行业内最大企业之一目前正进行的宣传。他们把物联网称为“一次处于常开状态的革命”，从边缘节点/感测器节点(即从物的一侧)收集到的资料随时都在向云端传送。这种方式须具备极大的网路频宽及强大的存储能力用以从云端收集资料，还须进一步提高其被动式大资料分析能力，以处理来自云端的如此海量的数据。
很明显，他们要销售的是锤子，所以就把世界上的所有事物都视为钉子，而真实的情况是，物联网是一个“在大部分时间处于关闭状态”的系统，其所产生的数据比他们的描述要少得多，而且很少会有数据能最终到达云端(图2)。举例来说：
图2 物联网多元应用将包含高速、低资料量传输需求。 资料来源：Atmel
1. 一扇门或者一把锁大部分时间都是处在休眠状态，直到感测器在开门或者接近门锁的过程中触发一个唤醒指令，才会将几个字节的数据传送到闸道器，然后重新回到休眠状态。
2. 桥梁上的温度感测器会每隔一段时间就从休眠中醒来一次，将温度的变化情况即时通报给路边闸道器，同时告知桥梁是否结冰，是否须通知交通部门派除冰车过来以避免交通事故发生。
3. 在美国德州，安装在写字楼空调上的震动感测器会每2小时监测一次空调压缩机运行的声音。如果压缩机声音中有迹象表明，这部空调有可能会在几周之内出现故障，那么感测器就会马上给大楼物业发出信息，让其派一位技术人员排除潜在故障，以免在火热的7月空调突然停止工作。
4. 在拖挂卡车所运送的水果集装箱，乙烯气体(水果和植物成熟时所散发出的植物激素)探测仪每隔30分钟醒来一次，将集装箱内的数据传送给卡车驾驶室内的闸道器。通过这些资料可预测出水果的腐烂速度，让司机在必要的情况下将运输目的地临时更改为就近城市，从而让水果可以有更长的保质期，或者将水果直接送到果酱加工厂，避免水果腐烂的同时还浪费卡车燃料。
上述每种情况，以及类似的其他情况中，物(即水果集装箱、空调、桥梁、门锁等)的大部分时间都是处在休眠状态，只有在某个事件触发下或在预先设定的时间间隔内才会苏醒一次，只有透过这种手段才能够让这些设备仅依靠电池就可以运行长达数年的时间。
所有事件是否都值得发送到云端?实际上，在本地闸道器运行的本地事件处理和分析引擎将决定什么内容须发送到云端，只有在出现例外事件时(门打开、水果变质、压缩机出现故障、桥梁结冰)讯息才会立即传送到云端。除此之外，只要一切都处于正常状态(处在预先设定的允许范围之内)，数据就会按照预先设定的时间间隔(如每24小时一次)进行记录且元数据将会上传至云端。即使涉及到视讯采集，所需频宽也不会超过2Mbit/s。
根据笔者对多个拥有大量建筑的大型企业和校园的分析结果，物联网服务在不提供视讯功能的情况下，总计只需要15Mbit/s最大频宽就能完全支援物联网在提供服务的过程中与云端之间的通讯。所以对于那些鼓吹所有应用和物都保持常开状态，因而需大量频宽资源的人，应持怀疑态度。
多方合作追求物联网系统层次设计
他们将物联网做这类描述的目的何在?当然，如果我们所考虑的企业校园到处布满智慧终端设备，人们随时都在利用“对话频繁和持久的通讯手段”传输大量数据，那么肯定须要比15Mbit/s更多的资源与云端保持连接。
是不是这些人将IT基础设施与物联网基础设施混为一谈?为全面实施物联网，就须要采用系统层次的方法(图3)，以覆盖从最细小的边缘/感测器节点(物)、各种不同类型的闸道器、一直到云端和数据中心、各种应用及服务供应商等各方面。其中包括嵌入设备或云端的数据分析引擎，带有各种软体开发套件(SDK)、通讯零组件、资料缓存、不同层级的频宽管理等工作，而全世界有能力将所有上述各项需求都集于一身的企业则是屈指可数(只能达到个位数)。
图3 物联网设计须涵盖软硬体系统方案才能实现。 资料来源：Atmel
即使能够具备这种能力，企业依然需与小设备/物一侧的企业结成合作夥伴，因此当某个人声称他们可提供一站式服务时，实际情况是：他们或者能支持某种现有物联网基础设施与云之间的通讯，并为其增加某种新特性(大部分物联网垂直市场的某种子设备)，或者系统并不如他们所说的全面，甚至是这两种情况都存在。
更不用说，现阶段使用者能选择的无一例外地都是各自独立的云端和物联网系统。虽然某些公司已开始开发一种云生态系统(即所有云的云)，但是在成为真正的物联网云生态系统之前，他们还有很长的一段路要走。
IT云生态系统(与物联网云生态系统相对应)历经过去几年的发展，正如最初所预期的那样，随着技术不断推广，一个无缝的和无限的虚拟环境逐渐出现，在这个环境中，通讯、存储、运算、网路和行动服务、资料分析，以及其他的商业目的都可以得到实现。
随着需先期资本支出的项目极大地减少或消失，云端服务收益模式也开始结出成果。其中包括用户可扩展性变得更加灵活和可控，不同企业可按照需求自行增加功能，以及由此而带来的即付即用等好处。云服务提供商将承担起许多企业对IT方面的要求，并成为他们至关重要的商业和通路合作夥伴。
物联网云端需求迥异
虽然有上述的种种成就，根本问题依然是：传统IT云及生态系统与物联网是否一致?答案是：虽然60-70%一样，但另外30-40%差异会让业者推出的产品铩羽而归，让看上去是为物联网准备的云，对目标应用却几乎毫无用处。
这种差异几乎存在于整个端到端系统当中，从“物”的一侧一直到云端资料中心无一例外。传统IT云、网路或行动应用云通常代表着较大的设备和较为丰富的云资源;而传统云系统中的物通常都由伺服器、自动售货机、汽车、闸道器、或智慧终端(笔电、平板、智慧手机等)所组成。
这些设备通常直接透过蜂巢式网路连接、无线广域网路(WAN)+无线区域网路(Wi-Fi)(LAN)、或光纤(WAN)+Wi-Fi(LAN)与云连接在一起。而新一代物联网中的物则更多是资源极为有限的设备，例如安装在门廊处的感测器一般利用小型电池驱动，用于探测通过后门进入房间的人，还有安装在道路设施(桥梁等)上并以电池驱动的震动感测器，以及在之前列出几个例子中的设备等。
过往的情景是在一间办公室里有二十部智慧终端设备，这些设备以墙上的电源插座供电，或透过容量较大且会定期充电的电池提供电力;相较之下，物联网云及生态系统的情景就是在同样规模的办公室里有五百种不同类型的感测器和物，如果有多间办公室，数量更会多达上千个，且大多数都在电池的驱动下工作长达数年时间(消费级别的物联网电池寿命为4-5年，工业物联网的电池寿命为8-12年)。
许多物联网装置安装一颗小型8位元微控制器(MCU)为大脑，具有极有限的内存和其他资源，也许还须安装在好几层的闸道器、继电器、开关，甚至是其他的物之后，位于一个处于休眠状态的网路里。当通讯连接开启时(要记住大部分时间内这些微控制器都处于不工作状态)，频宽非常窄，讯息可能会在网路中通过几次传递。对于那种对话频繁、定期向物发出Ping指令模式的通讯系统来说，这种要求肯定难以满足。
物联网云端发展十大要素
极为重要的一点是，物联网系统须能进行全面扩展和升级，且这种扩展不仅在云端侧，而是在云到物之间的连接一侧，甚至在物的一侧都应该是可行的。除安全通讯系统外，资料采集和收集能力同样也须是可扩展的，如果业者的目标是消费应用程序，那么最基本的要求之一就是要有可靠的行动应用开发平台，且能支持最常用的智慧手机操作系统。
换句话说，开发者必须让中介软体(Middleware)变得更加灵活、可扩展、能同时管理更多的物;还须对过去的整个通讯拓扑进行反思。最后，则要对分析引擎和应用开发环境给予更多的关注，根据所要开发的物联网应用程序不同，可能需要完全不同的视觉呈现工具和商业模式。
下面是IT云端供应商向物联网云端服务转型时须考虑的十大要素：
了解目标应用垂直市场
首先要理解目标垂直市场，为此提供一站式服务。在物联网中并没有一个可解决所有问题的万能方法。要了解某个垂直市场，就要考虑这个市场的变迁过程及未来的商业模式。例如，如果目标是随时随地追踪医院里的人员及其具体位置，那么可能须使用带有生物计量感测器的可穿戴设备，而且这些人的生命征象料也须监测。
此类服务虽可满足生物计量感测器的追踪，但内建感测器通常是由电池驱动的小型设备，可提供的频宽也是非常小的。在这种情况下，服务供应商与PaaS或SaaS业者合作管理其位于同一区域的设备;另一方面，若与云端服务业者合作管理另一套独立的设备，这种方案就不在可选范围之内，因为须考虑的问题包括通讯协议、网路、频宽管理，以及物联网云端架构须支持的传输技术等各个方面。
系统资料分析和运算
可扩展的资料分析及事件处理引擎都须具备。因为物联网的增值作用主要来自于资料分析，而“资料资本”则是差异化的根本所在。在云端及本地/闸道器一侧是否具备合适的分析工具引擎?而新的储存技术可改善数据处理速度，所以在某些物联网应用中也是必需的，因此传统的资料提取、转换和加载(ETL)模式将让位给准时性(JIT)方法(即实时方式与批处理方式的对比)。
另外，供应商是否有能力管理媒体资料分析及处理过程，以应对那些需即时数据处理能力的物联网应用?例如，在远程医疗保健和老年人监控应用中，位于云端的被动数据处理已无法满足要求，必须运用本地智慧闸道器，提供快速分析才能够应对诸如突发心肌梗塞或家用自动设备失火等紧急情况。
监测并采集资料
详细了解须监测/采集的是什么类型的数据，以及客户需要什么样的分析结果。也就是说，针对具体功能开发出一系列的设备数据模型。不要让自己成为物联网云解决方案中的“万能瑞士军刀”。因为虽然瑞士军刀可做许多事情，但这并不意味着瑞士军刀能把所有事情都做好。了解妳所要服务的垂直市场(要素1)对本要素的实现同样具有帮助。
某些应用中，在利用分析工具和可视化工具对资料进行处理前，首先须透过外部分类算法和丰富的工具进行资料组合。这个过程可大幅提高资料使用效率和方便性(例如在打开前须了解水网管线的位置，在为货物重新确定路径前须了解其他集散中心的位置等)。
端对端系统转向模组化
开发一个完全模组化的端到端系统。因为大部分的大型原始设备制造商(OEM)可能已有自主品牌的云服务，他们所需要的只不过是你所提供服务中的一部分内容。所以要提供定位明确的API，以及对防火墙友好的具有适应能力的连接架构，并且要熟练地使用客户基础设施、分析工具引擎、应用程序、视觉化工具等。
客户感兴趣的也许只是你的通讯系统，或者仅需功能上的某种结合。物联网方案供应商的方法愈灵活，就愈能满足客户需求。在云的一侧，云生态系统的形成就是下一个任务，一个强大生态系统将是物联网云管理的核心所在。
上文提到的模组化系统也许意味着为物联网商业模式建立一种分层的定价方法。灵活性应该不仅存在于技术产品中，厂商应对新的商业模式持开放的态度。
物联网标准搭建生态系统
在新服务架构之后应跟随大的生态系统，例如开放互连联盟(OIC)等。在消费性和工业级物联网领域，标准化将最终占据主导地位，尽管由各种字母符号的简称所组成的通讯协议(如MQTT、XMPP、DDS、AMQP、CoAP、RESTfulHTTP等)可能会继续发展，标准化也同样处在进行当中，故厂商要做好升级的准备，因为专有系统也许在将来须要向标准系统升级，才不致脱离生态系统。
广泛的无线通讯设计技能
培养在无线通讯领域的专业技能(蜂巢式网路、Wi-Fi、BLE、802.15.4/ZigBee、6LoWPAN、Sub-GHz、SigFox等)(图4)，或者与具备此项技能的一方合作。许多IT云企业在这方面都存在很大缺陷，须寻找一个合适夥伴来优化IT云，使其能支持上述复杂的通讯协议。他们同样须在无线连接的类型及有限频宽基础上，对系统进行优化。
图4 物联网引爆多元通讯技术导入潮。 资料来源：Atmel
对于应用开发方的人员来说这一点同样有效，因为物联网的定制化工作是必须的，且通常针对蜂巢式网路技术行得通的方案，挪到Wi-Fi、BLE或ZigBee上未必行得通。当所设定的目标是某个垂直市场时，这一点尤其显得重要，因不同市场需要的是不同的无线通讯协议，甚至同时需要多项技术，所以会遇到不同协议共存所带来的问题。
轻量化SDK设计
无论SDK是自有还是其他形式，供应商都要搭建一个轻量级的通讯系统。典型SDK虽让行动应用程序的开发和管理变得更加方便，但是与那些负责向物联网系统传递数据的细小且资源有限的感测器相比，智慧手机所拥有的资源显然要大得多。轻量级的SDK具有更高的可预测性，也更加容易与内存有限或经由电池驱动的设备整合在一起。
随着设计逐渐延伸到闸道器层级并有愈来愈多类型的机制、功能、感测器、通讯和警报须监测，SDK的规模就会增加。确实没有一种方案是万能的，但是在应用和数据管理方面永远保持节俭的态度一定是有效的。到目前为止，根据笔者与各种物联网云生态系统夥伴的合作经验，SDK在记忆体使用量的大小从3K-150K不等。物联网云的发展之旅已经开始，相信在不远的将来更为高端的方案(以及一些中间步骤)将会减少，而缓存机制将会愈来愈壮大。
另外，要部署一种以具体环境为中心的频宽管理系统，如此一来，系统将不会仅因为管理层面的活动就占据所有频宽资源。经验告诉我们，在与中间代理和缓存功能的通讯连接中，所占据的频宽不要超过15%。
物联网系统使用方便性
物联网的重点放在方便使用上，也就是说，提供的设备要便于使用，让即使是一个物联网开发的新手也能按照步骤自己完成相应工作，无论采用何种传输技术或可用资源是多少。如果所花的时间太长、错误多，或需大量开发人员针对某个架构进行调整、定制及优化，那么供应商的目标市场就只剩下那些大型OEM了。 如果供应商选择与软体服务企业合作，虽然可让进行更好的升级并获得额外频宽资源，但代价是提高成本。与其如此，不如从一开始就让整个过程变得极为容易，从而可最大限度地覆盖潜在用户;换句话说，从物/感测器API的编写，到本地闸道器和云闸道器，再到智慧装置、通讯及服务API的编程，无一不将重点放在简单易用上，以便为客户带来开箱即用的体验。
可视化工具和用户体验
关注系统中各个组成部分的可视化工具和用户体验。物的虚拟化和可视化(包括应用程序，将设备数据模型转化为云可理解的讯息)是一个很大的价值命题。若供应商目标是消费性物联网垂直市场，且智慧手机在其中占据非常重要的地位，那么所提供的服务应包含一个强大行动应用程序开发环境。IT云和物联网云都有各自不同的数据消费人群，具备出色的可视化特性可提升竞争力。
物联网安全与认证机制
最后，也是非常重要的一点，是否具有一个强大且牢固的安全和认证机制，且采用非常先进的加密算法?是否支持错误修正码(ECC)和AES-128/256?是否拥有以物理反复制技术(PUF)为基础的密钥生成机制?物联网领域存在着极高的风险，须在系统安全上花费更多精力，从拥有有限资源的物一直到云端，各方面都须考虑。
不过，目前物联网应用开发人员对安全知识了解程度依然不高，云端合作夥伴须具备相应能力，贯彻和实施安全设计。
在物一侧须保护的基本要素包括安全引导、物的身分认证、讯息加密/完整性，以及可靠的密钥管理和存储流程。通盘了解物联网云端需求的半导体合作夥伴，将能从“物”的安全角度帮助服务供应商优化系统。
(本文作者为Atmel副总裁兼无线解决方案总经理)
