|
当你看到秃鹰粉饰自己的羽毛把自己打扮成孔雀时，你知道，它们肯定嗅出了不寻常的味道。微软和谷歌分别高调宣布以其HealthVault和 GoogleHealth服务进击医护领域，同样昭示出它们意欲图霸该市场的雄心。此举并非仅仅揭示出个人保健市场的前景，还表明，它们很看好日益壮大的 机对机通信(M2M)市场。无论是远程个人保健、抑或智能交通系统和能源管理，监测远程设备和资产的能力越来越被看作是IT巨头的下一餐饭票，这种能力有 可能催生一个令目前计算市场相形见绌的产业生态系统。
数年来，虽然若干咨询公司在M2M市场斩获颇丰，但它更多的还只是引发人们无助遐想的一块领地。它具体表现为一些“有趣”、高度垂直的应用，如统计自动售 货机内的可乐罐数或跟踪物流货车的位置。这样，M2M市场就被分割为许多特定应用，引人注目的是它们大多各自为政。移动网络业已进入该领域，但许多应用对 数据量需求不大，所以，无法提供可维持其兴趣的和约收入水平。若你每年在这上面花不到200美元，则他们(移动网络运营商)就没兴趣。所以，对大多应用来 说，其发展或得到强劲用户需求的拉动或有技术供应商背后的鼎力支持；蜂窝调制解调器产业就很好地诠释了后一种情况。
正在改变这种局面的是M2M内两个关键需求力度上的改变——特别是对远程健康监测和智能交通系统(ITS)的需求。随着世界人口构成的改变，给保健、交通 和环境带来越来越大的压力。我们最终认识到，我们目前所有的系统真就无法满足需求。我们需更更广泛、更经济地监测人员、车辆和系统以避免事情向坏的方向发 展。政府认同这样的理念，整个行业对将成千百倍扩张的市场规模垂涎欲滴。
带动改变的因素显而易见。现有的保健体系受到迅速增多的诸如糖尿病等久治难愈慢性病的挑战，西方人口老龄化趋势加之支撑该保健体系开支的纳税人生力军比例 的减少，使局面进一步恶化。随着汽车保有量的增加，交通系统益发拥堵。会为拥堵付出代价，若路面交通体系要保持竞争力，最后可能会不堪重负。业已认同，修 建更多的路是“自限”之举。因此，政府开始严肃考虑迄今一直难以启口的道路收费这剂猛药并关注在迈向智能交通系统过程中蕴籍着的灵丹妙药。另外，随着各国 政府认识到全球变暖带来的实在威胁，若我们打算限制温室气体的更多排放，则更好地控制能源使用的紧迫性就迫在眉睫。
有这些问题几乎影响着发达国家的每个成员。各国政府亡羊补牢般地认识到，必须有所行动。对那些认为自己目前业务已过了高速增长期的IT企业来说，若能成功 登陆M2M市场并承诺可“解决”这些问题，则获得的不仅仅是增长，还将导致IT领域的彻底洗牌，使自己脱胎换骨为新赢家。这并非简单的扩大规模的问题；目 前的规模一般在几十万套水平，要达到几十亿的规模需重新审视通向M2M之路。问题在于，做秀式的营销套话，于事无补。M2M真正需要的是负责处理将数据从 资产传送到数据库一整套流程的低成本、标准化的端对端平台。
M2M不仅是数据库
M2M的主要应用——远程保健、道路收费和能源监测都是关于数据的。本质上，M2M与从“资产”上获取信息相关——无论是个人健康的某项指标；还是车辆的 行驶位置和驾车手法；抑或家里洗衣机的能耗。它基本上是关于与资产建立可靠连接以获取数据、并在中心数据库将这些信息收集起来然后加以分析的。一个同样重 要但常常被遗忘的部分是分析后的反馈——无论是对个人医护设备、对过路收据还是对家中获命洗涤内衣的洗衣机的反馈。
因M2M被视为最终是以数据为依归的，所以，那些竭尽所能作秀、力图以市场领袖或市场培育者身份吸引人们眼球的公司是那些相信它们在耕作这块市场并希冀被 看成是出类拔萃的那些公司。换句话说，是那些熟悉海量服务器和数据库的公司。
遗憾的是，弥漫在这些高调说辞周围的光环使到目前为止、一直以来妨碍着部署普及的一个主要障碍——从资产获取数据的物理机制——朦胧不清。我们看一看目前 大多的M2M部署就可发现，它们一般在几百或上千套规模且都构建在专属系统和硬件上。我们需启动的潜在市场绝非区区几十万甚或数百万，而是几十亿。单纯提 供设计精良的数据库和中间件API是无法实现该目标的。
另一个误区是没能理解，需要被监测的大多资产并不期望通过PC平台完成，它们也不会整合进一台嵌入式PC。这些资产有不同的通信需求——医疗设备希望能随 时随地进行通信，所以大体希望借助移动手机实现连接。就方便居家生活的传感器来说，它们需要与便宜简单的家用网关“说话”，家庭能耗监测的要求也一样。我 们汽车的“联系”对象是路边传感器，它会借助我们的手机或采用短距离无线网络完成“沟通”。大多这些设备本身并不太会整合蜂窝或传统的宽带链接。现实情况 是，它们将基于低成本低功耗无线连接搭建与网关设备的通信，这些网关设备可以是住宅网关、市政网络或移动电话。若想使它们遍地开花，就需找到一个安全、简 单、省钱的通信方法。
走进平台
这就是为什么在谷歌和微软的声明中失语的原因。它们都提供安全的数据库，这虽然是方案的重要部分，但毕竟只是一部分。要从眼下可怜的安装基数上扩展其规 模，那些打算扮演重要角色的公司需要了解，它们必须支持一个完整平台，该平台要覆盖从资产数据到安全数据库这一完整生态链。然后，企业或公共应用可构建在 这些数据库之上。另外，真正平台需设计得足够简单以与低成本硬件一道工作，因许多这样的资产传感器将以经济的MCU为基础——这与以Linux或 Windows为根基的概念大不相同，在那种应用中，大公司似乎自认为唯我独存。
为理解该M2M平台的真实特性，检讨一个M2M应用的架构将功不虚弃。任何这些应用存在的理由都是资产，它包含我们需要监测的数据。基于我们讲述的事例 (也许是件趣事)——许多这些研究偏爱举定位失窃的法拉利跑车或监测一个患有致命心脏病名人的体征这样的例子。现实中，大多应用会更朴素，但却紧要得多。
在将配备有数十亿设备的真实M2M世界内，简单就是王道！就保健领域，所做的大概就是简单的脉搏和体温测量或病床使用情况感知。在此有个重要分野：珍贵资 产可承付昂贵的数据采集费用；但大众应用不能。对法拉利和名人的监测请得起身价不菲的顾问设计预制产品。但M2M的未来需构建在现成的构造模块上，正是它 们将构成我们憧憬的数十亿规模的大部。为接入它们，业界需经由改变心路及借助为这些最大众化需求开发可调适端对端平台的作法上路。
我们开始检讨端对端平台这一概念。下面的图表将一个端对端平台分解成各要素。
数据采集层
无论我们打算监测的平台怎样工作——是带GPS功能的复杂数据记录仪、还是简单的通/断开关，它都产生数据，端对端平台的概念正是在此展开。在平台底部， 数据采集应用要能读取或接收该数据、之后要将其转换为可被安全回送至数据库的格式。这就是数据采集层。
若数据实时性很强，则必须立即回传。更常见的情况是，先把数据储存起来然后再传送会带来好处。还有一种情况是将上两者结合起来：例行数据先被收集起来，而 重要变化或警告则需立即告知。这些决定是由附接的本地MCU或嵌入在资产内MCU内的嵌入式固件管控的。该固件还负责管控与服务器的回传、认证链接以及数 据在一个周到设计的平台内被传送前的加密。固件还能在远程服务器应用的命令下调适其记录行为，从而具有灵活性并可被升级、注册和重新配置。固件按照约定标 准将数据格式化，这与医疗设备要符合IEEE 11073规范一样，该固件与其在中间件内对应的应用一道还将负责保证数据是以正确格式存储的。该固件及其运行于上的MCU就构成数据采集层。
通信层
在采集完数据并对数据格式化后，平台需与远程服务器通信。通信可采用有线或无线方式。具体抉择独立于端对端方案的架构，但应取决于应用实际，如：资产可能 的位置和流动性、实时性要求、数据量、通信成本和资产内的可用电源。重要一点是：端对端平台不应牵扯通信信道，它唯一需要的是基于可靠有效方法上的通信。 对高价值移动资产来说，可能采用蜂窝连接；若数据量大，则一般选Wi-Fi或宽带；对许多医疗和传感器设备来说，连接可采用移动手机或经由家庭网关的 Wibree(蓝牙ULP)链接。这是通信层。
因简单设备的处理能力有限，所以为传输数据，应对数据和命令协议实施优化。这可能需再次求助嵌入式协议工程师的专长，且最好别等到回天无力那一步。依赖眼 下风头正劲、互连网界追捧的XML将浪费可能无处可寻的宝贵通信带宽资源或使通信成本太过高昂。
中间件和数据库层
在此，由IP载负的数据直接在因特网或借助连接至因特网上的网关流送，经此它到达中间件层。中间件执行若干任务。其首要工作是对资产设备的认证以确保来自 不同设备的数据绝不会混淆在一起并规避黑客对中间件的攻击。它还控制远程资产的功能——在需要时发出控制信息以确证实施中的数据采集和通信行为。在完成这 些任务后，它运行资产数据的解密和重构等服务器端任务(若为了方便传输对数据进行过压缩的话)并安全地将数据存放在数据库内。只是在这个地方，我们开始触 及微软和谷歌所抛出的平台“定义”。但，无论其平台设计得多巧妙，若没有上面提及的端对端平台要素，该平台就没价值，因它没能提供一个从资产获取数据的具 成本效益的方法。
在数据库之上是一组将数据提交给上层应用的API。眼下，许多这些应用是为那些推广其独有M2M系统的公司所定制的专用、垂直的企业方案。未来，情况可能 会大有不同。数据将不仅被用于单一客户，而是不同服务都可能使用或接入该数据。例如，政府可将车辆信息用于道路收费、汽车制造厂可将其用于计划的维护、而 车主可将良好的车况和驾驶记录“卖”个好价钱以获得最优惠的保险条款。类似，健康记录不再仅对口提供给我们的保健机构，还可被自助组织匿名整理或出售给药 厂。一旦这些平台各就各位来监测亿万用户，利用这些数据的新网络服务将被以比目前用于数据安护的藩篱式手法远具创意的方式开发出来。在此，M2M与Web 2.0交汇。
但，要实现该目标，我们要停止谈论范围有限的平台，而是努力开发、推介巨细无遗无所不包的端对端平台。再回来检讨M2M架构，我们就会看到，无论微软还是 谷歌宣称的平台充其量也就覆盖了上述完整平台的一小部分。
将餐馆内的一顿饭考虑成端对端处理流程的终极结果是个有益类比。整个平台包括许多你看不到的东西——农民、酒商、面包师、厨房供应商和厨师。若全都没有这 些，你可享受到温馨服务和优雅环境，但最后端上来的却可能是半生不熟的夹生饭。这正是微软和谷歌提供的——折叠整齐的餐巾、穿戴得体的服务员，但就是没有 食物。若你要享一顿色香味具佳的口福，需要全部这些要素。另一方面，该比喻推而广之，就目前的M2M状态来说，我们还并不了解餐厅是什么样——我们仍是在 家中厨房做饭。
就M2M能有所突破并取得成功来说，需要了解的一点是：需要一个全方位的覆盖硬件及基于服务器软件的端对端平台。需对这些进行优化以便与不贵的传感器以及 更复杂的数据监测一道工作。如微软提议的，显然可基于PC或复杂的嵌入式微处理器来搭建平台，但此举仅关涉到少量高价值的一系列“明星”传感器。为完全满 足量众M2M部署的需要，我们需一种既可运行于非常简单硬件又可工作在更复杂系统的方案。
实现真正端对端平台的策略
显然，从标准化数据库和API出发并不足以济事。设计师需能开发出可根据应用进行调适的兼容硬件方案。它们要能感知这些应用可能需要的批量和潜在价格点。 这意味着一组完整的协议集要既支持低于5美元的床位感知器还要适用于多输入车辆跟踪器。但对每个应用来说都应是相同协议集。最终应用也许大相径庭，但数据 的采集、传输和存储过程本质上对每一具体M2M事例来说都是相同的。
为实现上述目标需更多标准化方面的工作。在远程保健应用，Continua保健联盟(Continua Healthcare Alliance)在尝试定义标准，但就通过以开发出更好的数据传输定义和规整选项的方式来实现一个更广泛、通用且与最低端传感器仍具有非常友善交互界面 的方法一事有很多争论。
那些执意要在此市场扮演未来重要角色(或渴望占有一席之地)的公司需在此制订规范的过程中发挥更积极的作用。不仅是微软和谷歌，还包括IBM、 Oracles和SAP等该领域不可避免会对市场产生影响的重量级玩家。目前，这些大公司基本游离于这些标准组织具体事务之外——但它们要明白，它们必须 参与、帮助推介开放架构和协议。最终的协议无论是开放的或授权许可的，都必须保证经过验证的互操作性和可用性。最后一句极其重要——我们的M2M设备需要 智能，它将允许设备之外的自动配置和注册。没谁有财力负担一个10亿计的保健和车辆传感器支持中心。
这样一个平台还迎合了政府要求。如我们看到的，改变的人口结构以及不断增加的久治不愈的慢性病患将导致保健资金的不可预见性；越来越多的车辆将引发交通堵 塞而对环境的关注将导致立法以在能源使用中强制实施自动化智能监管。这些都是需要通过数十亿个互连的传感器才能解决的问题，而每个这样传感器的最终制造、 安装和服务成本都应在10美元以内。
在著名的原动议间会出现一些有趣的协同。Android作为服务网关平台的潜能就是一直没被关注的事例之一。但，它属于不经意间出现且有可能做大的那种， 而不是一门心思要攫取市场的那一类。
机会巨大。但赢家不会是小打小闹又自吹自擂的玩家，而是那些高瞻远瞩统揽全局且其包罗万象的标准化方案能包纳全部这些需求的公司。
