理解物联网的互操作性
一开始，我们有M2M。然后就是物联网。随着工业物联网和围绕IT/OT集成的挑战，我们看到了云计算、边缘计算和雾计算等术语。
现在，热门的术语是互操作性。互操作性对经常使用新术语和价值主张的技术行业很有吸引力。在采用者组织中也有一些愿意的受众。他们中的许多人开始在日常运营中看到各种各样的应用机会。与此同时，他们担心构建一整串断开连接、孤立的物联网应用程序会带来经济和技术上的陷阱。
在物联网解决方案的上下文中，如果不使用限定词(如“between”)，互操作性就没有什么意义。考虑一下这句话:“我有一个提供数据互操作性的解决方案。”例如，在添加“在您的传感器和我的应用程序之间”这两个词之前，这没什么意义。
水平和垂直维度上的互操作性
在实践中,并发症与互操作性它在物联网环境中的使用有几种排列。考虑以下两组物联网解决方案栈的框图:
一个物联网应用程序(App#1)可以通过中间件平台(MP#1)与相关传感器(传感器#1)通信。它甚至可以根据传感器数据向执行器发送命令(执行器#1)。在图的右侧，第二个物联网解决方案也有类似的安排。
现在，假设有一种方法可以通过使用来自与App#2相关的传感器的数据来提高App#1的性能。如果App#1和App#2之间存在互操作性，这可能是可能的，要么通过外部数据交换(过度互操作性)，要么通过它们各自的中间件平台。另外，App#1可能能够访问传感器#2，因为它们各自的中间件平台之间具有互操作性。这个场景帮助我们考虑水平互操作性方面的应用程序能够发现资源(例如，其他应用程序、其他中间件平台、其他传感器/执行器等)，以识别它们提供的服务(例如，发布的数据流、远程驱动、以及通过交易来使用这些服务(例如，发布-订阅解决方案栈数据，对收费和结算的使用跟踪，等等)。
在这种任意对任意交互的场景中，可能会出现这样的情况:解决方案所有者找到了更好的传感器(更高的性能)，或者以更低的成本或更高的可靠性提供相同级别的性能。App#1的所有者可能希望更换供应商，或者通过用供应商b提供的更好的产品替换供应商a的传感器#1来操作一个多供应商解决方案。这个例子从垂直意义上提供了技术和供应商互操作性的另一个角度，从价值堆栈的上下。
到目前为止的讨论考虑了两个应用程序场景中的框图构造。这种安排的实际实现涉及来自不同供应商的硬件和软件。如果解决方案所有者希望更改网关如果使用来自不同供应商的产品，它将重视网关到中间件(以及网关到传感器)的互操作性，从而最小化定制系统集成工作。这种互操作性类似于电脑连接互联网或移动电话能够在国际上漫游。
在当今的云计算世界中，支持物理互操作性的一个例子可能包括托管在Amazon Web Services上的应用程序(及其数据)与托管在Microsoft Azure上的另一个应用程序协作。这种安排是否提供了两个云基础设施服务之间的双向互操作性(包括通信、服务水平、数据语义等)，还是依赖于中间翻译程序?
物联网互操作性的战略意义
考虑到这些不同的观点，为什么组织从战略上思考物联网互操作性很重要?至少有三个原因。首先，组织需要决定是投资单个应用程序还是竖井应用程序。例如，他们只是希望在运行寿命基本不变的多年的工厂机器上应用状态监控应用程序吗?或者，他们是否希望支持具有相同连接设备的其他应用程序，从而发现自己在未来支持多个潜在的跨竖井或跨供应商的应用程序?这是一个问题产品路线图规划。
其次，物联网技术的用户是否将自己锁定在单一技术或单一供应商的解决方案集合中?有一种方法可以绕过这种困境。例如，许多电信运营商依靠基于标准的互操作性在其网络中部署多供应商基础设施。其他行业可以借鉴这一战略。工厂、办公室和家庭是存放来自多个供应商的机器和电器的地方，这些设备和电器在未来的某个时刻要求设备(端点执行器、传感器和网关)和应用程序之间的互操作性。
第三，物联网技术的用户需要认识到技术的不断发展及其对更高层次解决方案的影响。虽然今天的互操作性辩论集中在通信和硬件兼容性上，但未来的解决方案将把互操作性挑战转移到更高的价值堆栈上。
考虑一个涉及多个交互系统的场景，这些系统对交换的数据块具有相同的含义。这确保了跨系统的数据一致性，而不考虑单独的数据格式。在实践中，这可能是一个温度传感器提供多个物联网应用的一系列数字;每个应用程序都将对数字流应用正确的含义(即，将它们识别为温度数据，无论是摄氏还是华氏格式，而不需要在应用程序中硬编码配置参数)语义互操作性在传感器和应用之间。
技术发展的问题在于，它具有长期的时机选择和投资影响。这对投资决策和支持未来新应用程序和业务模型的固有选择价值有长期影响。
所有IoT Agenda网络贡献者都对其帖子的内容和准确性负责。意见是作者的，不一定传达物联网议程的想法。