借助平台互操作性打造物联网生态

主要结论

• 对单一利益相关者而言，门槛过高，潜在利益过低，物联网生态目前依然没有实现足够有活力的合作关系。
• 对物联网生态的开发来说，根本性障碍在于不同物联网平台和物件之间缺乏互操作性。
• BIG IoT（Bridging the Interoperability Gap of the IoT，弥补物联网互操作性鸿沟）项目旨在促进跨平台、跨标准、跨领域物联网服务和应用程序，共同塑造物联网生态。
• BIG IoT API 提供了身份验证和授权、资源注册和发现、记账、资源访问等能力。
• “市场”是 BIG IoT 架构的一个重要组件，资源提供商和消耗者可以在这里发现彼此，交流并交换资源，并执行收费、记账、支付等操作。

本文首发于 IEEE Software 杂志。 IEEE Software 针对当今世界的主要战略性技术问题提供了坚实的同行审阅信息。为了应对企业在可靠性、灵活性等方面提出的挑战，IT 经理和技术主管必须依赖 IT 专业人员才能获得最先进的解决方案。

物联网的碎片化和互操作性的缺乏使得物联网生态难以被更广泛地接受。旨在促进整个生态进一步发展的 BIG IoT（Bridging the Interoperability Gap of the IoT，弥补物联网互操作性鸿沟）项目应运而生。

物联网已不再是遥远的梦想，正在逐渐成为现实，具体应用场景已陆续涵盖从自我量化和智能家居，到智慧城市和数字化健康，再到工业 4.0 等不同领域。这一过程中还涌现出大量物联网平台。你可能已经想到，其中也包括云解决方案，如 Evrythng 、 ThingWorx 、 Xively ，或 Yaler 。此外还有很多本地部署的解决方案，例如 Bosch IoT Suite ，以及侧重于特定领域或地理位置的平台，例如主要针对意大利皮埃蒙特（Piedmont）区的 SmartDataNet 。

然而对单一利益相关者而言，由于门槛过高，潜在利益过低，导致物联网生态目前依然没有实现足够有活力的合作关系。平台、物件，以及服务的提供商希望通过简单、成熟的方式销售由自己提供的可访问资产，但目前尚不具备可以让这些提供商从中变现的市场。一旦这样的市场顺利上市，开发者将可以轻松地创建物联网服务和应用，并围绕这些东西构建自己的产品，随后即可跨越不同的组成实体（服务、平台、物件提供商）实现营收来源的共享。此类市场的一个重要任务在于提供可扩展的功能实现宣传、动态发现、自动化编排，以及服务协商，借此促进市场中所提供内容的使用。

然而在市场能够全面提供所有价值之前，依然需要克服物联网生态目前面临最大的门槛：不同物联网平台和物件之间互操作性的缺乏。现在，我们已经看到了面向各种垂直行业，但大部分都维持封闭状态的系统。物联网架构往往基于异构标准构建，例如 Constrained Application Protocol（CoAP）[1]、Message Queueing Telemetry Transport（MQTT）[2]、LightweightM2M（LWM2M）[3]、Sensor Web Enhancement（SWE）[4]、oneM2M[5]，甚至各种专有接口。

因此大部分现有和新兴的物联网平台会提供异构的方法，帮助用户访问物件和相应的数据。但如果开发者希望创建可适用于一切情况的跨平台、跨领域应用，这种方式可能会在互操作性方面造成问题，并最终影响到物联网生态的良性发展。此外这也会对商机造成不利影响，尤其是小型创新企业，他们可能无力承担将解决方案适配到多个平台的成本。他们只能针对少量平台提供应用和服务，例如针对特定城市的物联网平台提供交通信息应用。

BIG IoT （Bridging the Interoperability Gap of the IoT，弥补物联网互操作性鸿沟）项目旨在促进跨平台、跨标准、跨领域物联网服务和应用程序，共同塑造物联网生态。这样的生态将能连接物件提供商、服务提供商，以及最终用户。作为该项目的一部分，我们已经开发出一套可解决互操作性难题的物联网生态架构。

向着互操作物联网生态努力

BIG IoT 的愿景与泛在或普适计算 [6] 的愿景极为类似，后者的目标在于让现实环境包含无处不在的计算能力。这些概念关注的是计算能力对用户的影响，相对的，我们有关物联网生态的理念关注的是技术设计和实现。我们的主要发力点在于通过技术为互操作性提供的支持，这一点类似于 Nicholas Loulloudes 与他同事的研究成果 [7]。然而他们的提议是通过某种解决方案管理可实现互操作的云应用，而我们对互操作性的支持是通过语义网（Semantic Web）技术在物联网应用、服务以及平台之间实现的。

例如，假设一个跨平台物联网应用需要访问用户可穿戴传感器组成的物联网平台，借此自动推断用户是否即将离开工作场所。随后，该应用程序访问智能移动平台购买通勤车票，并将用户导航到车票对应的座位。随后该应用程序联系用户冰箱所在的物联网平台，发现用户需要采购食品，于是在用户回家路上提醒她顺便去一趟超市。最后，该应用程序访问智能家居平台，启动暖气，在用户到家前营造出舒适的室温。同理，面向智能办公室的跨平台物联网应用也可以访问用户的可穿戴传感器，使用收集到的数据监控工作空间的环境状况。这种将不同物联网平台收集的数据以及物件本身用于多种用途的工具能为我们带来巨大的价值。

为了塑造这样的物联网生态，必须首先实现跨平台互操作性。开发者可以借助这样的互操作性将不同平台的数据（例如来自多个智慧城市平台的停车信息）结合在一起创建应用程序。同时，来自不同领域的平台也可以这样组合，例如将可穿戴平台与智能家居平台结合在一起。随后即可针对不同平台运行同一个应用程序，例如用同一个应用程序访问柏林、巴塞罗那，以及伦敦的智慧城市平台。

生态架构的一种模型

图 1 展示了一种生态机构的基本模型。不同物联网平台可供我们访问不同类型的物件，除了提供自己的接口，平台还可通过 BIG IoT API 进一步增强，这是一种通用接口，可提供与其他平台互操作所需的功能。平台可运行在“云”中（例如服务器或数据中心内）、“雾（Fog）”中（如网关或基于蜂窝通信的基站）、或设备中（例如树莓派计算机、可穿戴设备，或智能手机）。BIG IoT API 的内核可独自应用于不同平台并实现彼此交互。

(点击放大图像)

图1：一种物联网生态架构的基本模型。除了提供自己的接口，平台还可通过BIG IoT API 进一步增强，这是一种通用接口，可提供与其他平台互操作所需的功能。（图标由 Freepik 制作）

通过使用 BIG IoT API，为不同平台开发用作客户端的软件，这一过程将变得更容易。对于此类客户端，我们可以分为服务和应用程序。虽然这两者都需要消耗资源（信息或功能），但服务本身也可以提供这些东西。这样，服务就可以组合成更复杂的服务，或其他增值服务。提供商可以在市场中宣传自己的资源，借此消耗者可以发现资源并访问所需的提供商。我们预计以后会出现更多此类市场。

不同市场可面向不同应用领域（例如智慧城市、自动化建筑、制造业），而不同组织也可以针对某一领域搭建自己的市场。只要这些市场以及其中注册的服务和平台符合 BIG IoT API 标准，即可进一步促进物联网生态的繁荣发展。

为了在云、雾、设备层面上实现物联网平台的互操作性，BIG IoT API 提供了一套妥善定义的功能，其中包括七大关键功能。首先是身份管理，借此可实现资源注册。其次是根据用户定义的搜索条件实现的资源发现。第三个是元数据和数据的访问（数据拉取，以及数据流的发布和订阅）。第四是将命令转发至物件的任务。第五是针对不同概念语义描述的词汇 (Vocabulary）管理。第六是安全管理，包括身份验证、授权，以及密钥管理。第七是收费，借此可通过计费和支付机制实现资产的变现。

互操作模式

通过我们的这种架构模型实现物联网互操作性，需要密切留意重要组件之间的交互方式。在这种情况下，互操作性同时取决于接口的语法和语义。语法互操作性可通过清晰定义并且获得共识的数据和接口格式以及编码方式实现。语义互操作性可通过针对接口以及所交换数据获得共识的信息模型（例如所定义的本体 [ontology]）来实现。

图 2 展示了为了降低开发者门槛，物联网生态必须支持的五种通用互操作模式。跨平台访问模式（图 2a）是物联网生态互操作性必不可少的基本特征。该模式要求来自不同平台的应用程序或服务必须通过相同的接口规范访问资源（信息或功能）。例如，空气质量监控应用可以从不同平台提供的空气质量监测设备收集有关 NO2、CO，以及 O3 的检测数据。这种模式的实现会遇到两个挑战：首先，如何让应用程序或服务发现能提供相关信息的平台；其次，如何让不同提供商的平台暴露相同的接口，并使用相同格式进行数据通信。

(点击放大图像)

图2：五种互操作模式。(a) 跨平台访问，(b) 跨应用领域访问，©平台独立性，(d) 平台规模独立性，(e) 高级服务立面（Facade）。支持这些模式有助于降低开发者门槛。

跨应用领域访问模式（图2b）可对跨平台访问进行扩展。服务和应用不仅可以从多个平台，而且可以从针对其他垂直市场或应用领域的平台访问所需信息和功能。由于平台信息资源的语义描述可通过BIG IoT API 访问，将此类（原本异构）的数据集成至一个服务或应用的做法也变得可行。例如，一个可以从不同领域收集数据的应用，可以同时访问诸如O3 等空气质量信息，以及诸如平均速度等交通监控信息，借此提供空气质量更佳的自行车骑行线路。

平台独立性模式（图2c）要求特定应用或服务可以在两种物联网平台（例如位于不同地区）的基础上运行。为此可以让应用或服务发现相关物联网平台，并用一致的方式交互。例如，两个地区（如巴塞罗那和伦敦）部署的两套智能停车服务可能分别通过自己的平台提供停车位信息，如果两个平台的此类信息是通过不同类型的物件收集的，平台独立性的实现可能会面临挑战。例如可用车位信息可能是通过基于雷达的传感器收集，或通过街灯或地下安置的超声波传感器收集。

平台规模独立性模式（图2d）可将不同规模的平台集成在一起。云平台通常会管理大量设备并生成海量数据。雾平台可连接周边设备，管理特定时间和空间范围内生成的数据。设备平台可直接访问物件，通常只管理很少量的数据。

通过实现这种模式，平台可面对连接的服务或应用隐藏自己的规模。服务或应用可以用统一的方式使用来自云、雾，或设备层面的平台。例如，一个显示空气质量信息的应用（如，以可视化方式显示在地图上），可以通过云物联网平台访问汇总后的信息，例如计算后的空气质量指数。或者应用程序也可以直接访问空气质量检测设备（即雾平台）的数据，按照时间序列展示未处理的原始数据。

最后，高级服务立面模式（图2e）可将互操作性需求从平台扩展至更高级别的服务。这种方法使得平台和服务都可以通过BIG IoT API 提供信息和功能，因此服务可以充当物联网平台的立面（Facade），通过访问所提供的信息或功能提供增值功能。例如，空气质量检测应用可以访问平台A，获得汇总后的空气质量数据。或者也可以访问能够通过平台B 汇总空气质量数据的另一个服务，因为B 无法进行数据汇总，或只能提供长期内的时序数据。

这些模式使得服务能够重用和组合，并能将不同平台的数据轻松集成。我们对物联网生态的愿景还能提供更多收益。例如动态搜索并编排信息以及自动收费，这些有助于塑造更繁荣，更易用的生态。在这样的生态中，国界对应用和服务来说已经不再是问题。例如，通过智能停车应用，游客不再需要下载适用于目标国家的新应用。如果目标国家的平台提供的数据使用了兼容的语义框架，物联网生态即可让应用程序自动发现并连接至恰当的信息源，实现无缝使用的目标。

BIG IoT 架构

图 3 展示了我们的 BIG IoT 架构。其核心是一个开放的市场，物联网平台和服务可以作为提供商交易可用资源（信息和功能）。物联网应用或服务可以通过市场实时发现并访问资源。BIG IoT API 可提供：

• 市场所需的身份验证和授权功能，
• 市场中的资源注册和发现功能，
• 资源供应和消耗情况计量，以及
• 资源的访问。

(点击放大图像)

图 3：BIG IoT 架构，可支持图 2 所示的五种互操作模式。

市场和 BIG IoT API 是资源提供商和消费者相互发现、联系、交换资源，以及执行记账、收费和付款等操作的基础。因此市场和 BIG IoT API 也成了实现五种互操作模式的基础。

跨应用领域访问、平台独立性，以及高级服务立面模式面临的主要挑战在于，需要针对高度异构的实体实现互操作性：

• 跨应用领域访问主要以不同垂直市场或应用领域的提供商和消费者为目标。
• 平台独立性主要以托管在不同物联网平台的提供商为目标。
• 高级服务立面主要以使用不同提供商系统的提供商为目标，例如某个物联网平台或服务。

为了解决这些模式之间的互操作难题，该架构要求使用通用的信息模型，例如语义网和链接的数据供应 [8]。这些模型可支持（平台或服务）提供商通过可被机器理解的方式描述自己提供的资源，这样不同领域、地区，或使用不同系统的（服务或应用）消费者就可以理解并处理这些信息。就类似于我们可以通过 Schema.org 提供的词汇在搜索引擎和数十亿网页之间共享共识 [9]。

市场还会使用这样的信息模型，将提供商和消费者按照供应和需求进行匹配。为此数据提供商和消费者可以针对“智能对象”、“传感器”、“度量”共享词汇，这一点与搜索引擎与 Web 开发者就如何描述“餐厅”、“酒店”、“航空公司”等做法达成的共识类似。

在这样的架构中，提供商和消费者可以用类似于“类库”的方式实现生态系统功能。例如，提供商类库可以通过注册接口借助市场提供资源，并通过访问接口向消费者提供信息。这些类库可支持平台、服务，以及应用开发者交易、发现、访问资源。开发者只需要将提供商或消费者接口实现一次，即可轻松更新类库以满足底层消息格式和交互后续的需求变化。

BIG IoT 项目生态目前已包含八个平台，分别来自 Bosch、CSI（Consortio per il Sistema Informativo）、Siemens、VMZ（Verkehr Mobilit?t Zukunft），以及 Worldsensing。我们已针对移动领域进行了互操作性测试，包括智能停车、共享单车，以及交通管理。这些用力在实现方面使用了物联网平台和新开发的服务与应用，借此在巴塞罗那、皮埃蒙特，以及柏林和沃尔夫斯堡三个地区进行了演示和测试。为了展示五种互操作模式的实现，我们会在上述三个地区重用并转移所实现的服务和应用。

为了让这个物联网生态顺利成长，必须能够吸引开发者。但目前我们的方法存在一个最基本的风险：开发者和平台提供商可能觉得这个生态的功能（例如 BIG IoT API 和信息模型）不够有吸引力。我们会与利益相关者密切合作（例如进行调查和市场调研）以缓解这个问题。

更重要的是，为了让整个生态更有活力，BIG IoT 项目需要围绕物联网开发者社区打造开放的氛围。例如我们需要扩大社区影响力（例如举办黑客马拉松活动），以开放的方式发展 BIG IoT API（已得到万维网联盟 Web of Things 兴趣小组支持），将开发出来的软件以开源方式发布。

从概念和技术上来看，该项目还将在未来几个月里解决多种不同问题。例如将为市场和物联网平台之间的交互制定一种连贯的安全概念。这些平台通常都有自己的身份验证和授权解决方案，这会为市场的用户管理集成工作造成挑战。

此外，必须制定或重用一套通用的词汇和语义模型。此处的挑战在于，需要建立在各种开发者社区和标准化实体之间保持一致连贯的词汇。我们需要通过某种机制对词汇进行匹配和整合。以这些词汇为基础，即可针对物联网平台的资源定义相应的描述机制。

最后，该项目将为资源的智能组合定义一套机制，借此促进并实现最大化的资源重用。例如，将能借助车位查找和车位预留服务自动组件智能停车服务。

致谢

本调研得到了来自 BIG IoT 项目的支持，该项目已得到欧盟委员会 Horizon 2020 研发创新项目 688038 的资助。感谢合作伙伴的反馈和成果斐然的讨论。随着项目进展持续推动，我们的成果还将进一步完善。

关于本书作者

Arne Br?ring是西门子集团慕尼黑研发中心的研究员，同时也是 BIG IoT 项目的技术协调员。他的研究方向主要包括物联网、传感器网络，以及语义网。Br?ring 在荷兰特文特大学（University of Twente）获得地理信息学的博士学位，同时他也是万维网联盟成员。他的联系方式：arne.broering@siemens.com。

Stefan Schmid是 Bosch Corporate Research 的资深物联网专家。他的研究方向包括基于知识的服务、机器智能，以及语义互操作性。Schmid 在英国兰卡斯特大学（Lancaster University）获得计算机科学博士学位，他还是 IEEE 成员。他的联系方式：stefan.schmid@de.bosch.com。

Corina-Kim Schindhelm是西门子集团慕尼黑研发中心的研究员，她主要关注室内定位技术，因为定位有助于物联网更好地发展。Schindhelm 在慕尼黑大学（Ludwig-Maximilians-Universit?）获得计算机科学硕士学位。她的联系方式：corina-kim.schindhelm@siemens.com。

Abdelmajid Khelil是德国德国兰茨胡特大学（Landshut University）应用科学系的物联网和软件工程教授。他的研究方向包括物联网、机器间通信、车联网，以及重要基础设施的安全防护。Khelil 在德国斯图加特大学（University of Stuttgart）获得计算机科学博士学位，他也是 IEEE、ACM，以及德国信息学协会成员。他的联系方式：abdelmajid.khelil@ieee.org。

Sebastian K?bisch是西门子集团技术中心研究员，他的研究方向包括在物联网场景中高效实现并使用标准化的 Web 技术。K?bisch 在德国帕绍大学（University of Passau）获得计算机科学博士学位。他的联系方式：sebastian.kaebisch@siemens.com。

Danh Le Phuoc是柏林工业大学（Technical University of Berlin）的玛丽 - 居里学者（Marie Sk?odowska-Curie Fellow）。他的研究方包括通过数据链接和语义网打造未来的互联网，通过大数据实现的万物联网（Internet of Everything），数据库，以及普适计算。Le Phuoc 在爱尔兰国立大学（National University of Ireland）获得计算机科学博士学位。他的联系方式：danh.lephuoc@tu-berlin.de。

Darko Anicic是西门子集团技术中心研究员，他的研究方向包括 Web of Things 的开发和标准化，语义网，复杂事件处理，以及流推理（Stream reasoning）。Anicic 在德国卡尔斯鲁厄科技学院（Karlsruhe Institute of Technology）获得计算机科学博士学位，同时他也是万维网联盟成员。他的联系方式：darko.anicic@siemens.com。

Denis Kramer是斯图加特博世软件创新中心的物联网研究员，目前他还在德国奥格斯堡大学（University of Augsburg）有机计算（Organic Computing）系读博。他的研究方向包括物联网、机器学习、云计算，以及有机计算。Kramer 在德国比勒费尔德大学（University of Bielefeld）获得计算机科学硕士学位。他的联系方式：denis.kramer@bosch-si.com。

Jelena Mitic西门子集团技术中心研究员，同时也是 BIG IoT 项目协调员。她的研究方向包括普适计算、分布式系统，以及软件架构和平台。Mitic 在奥芬应用科技大学（University of Applied Sciences Offenburg）获得了通信和媒体工程硕士学位。她的联系方式：jelena.mitic@siemens.com。

Ernest Teniente是加泰罗尼亚理工大学（Universitat Politècnica de Catalunya）服务和信息系统工程教授。他的研究方向包括物联网、本体和概念建模、业务流程建模、自动化推理、完整性约束执行，以及数据集成。Teniente 在加泰罗尼亚理工大学获得计算机科学博士学位。他的联系方式：teniente@essi.upc.edu。

作者

Arne Bro?ring 、 Stefan Schmid 、 Corina-Kim Schindhelm 、 Abdelmajid Khelil 、 Sebastian Ka?bisch 、 Denis Kramer 、 Danh Le Phuoc 、 Jelena Mitic 、 Darko Anicic 、 Ernest Teniente ，阅读英文原文： Enabling IoT Ecosystems through Platform Interoperability

脚注

[1] C. Bormann, A.P. Castellani, and Z. Shelby, “CoAP: An Application Protocol for Billions of Tiny Internet Nodes”, IEEE Internet Computing, vol. 16, no. 2, 2012, pp. 62-67.

[2] IBM and Eurotech, “ MQTT V3.1 Protocol Specification ”.

[3] “Lightweight Machine to Machine Technical Specification, Candidate”, Open Mobile Alliance, 2015.

[4] J. Swetina et al., “Toward a Standardized Common M2M Service Layer Platform: Introduction to oneM2M”, IEEE Wireless Communications, vol. 21, no. 3, 2014, pp. 20-26.

[5] J. Swetina et al., “Toward a Standardized Common M2M Service Layer Platform: Introduction to oneM2M”, IEEE Wireless Communications, vol. 21, no. 3, 2014, pp. 20-26.

[6] M. Weiser, “Some Computer Science Issues in Ubiquitous Computing”, Comm. ACM, vol. 36, no. 7, 1993, pp. 75-84.

[7] N. Loulloudes et al., “Enabling Interoperable Cloud Application Management through an Open Source Ecosystem”, IEEE Internet Computing, vol. 19, no. 3, 2015, pp. 54-59.

[8] C. Bizer, T. Heath, and T. BernersLee, “Linked Data-the Story So Far”, J. Semantic Web and Information Systems, vol. 5, no. 3, 2009, pp. 1-22.

[9] R. Guha, D. Brickley, and S. Macbeth, “Schema.org: Evolution of Structured Data on the Web”, Comm. ACM, vol. 59, no. 2, 2016, pp. 44–51.