我们先有了M2M概念。然后又有了物联网。随着工业物联网和IT/OT集成的挑战，我们又有了云、边缘和雾计算之类的术语。

现在，热门话题是互操作性。互操作性对于经常出现新术语和价值主张的技术行业，非常有吸引力。在实施物联网的企业中，也有很多支持者。很多企业开始在日常运营中，看到应用机会的多样性。同时，他们也担心构建一连串无连接的，孤立的物联网应用，所带来的经济和技术误区。

在物联网解决方案中，在没有限定词时，比如“之间”，互操作性没有任何意义。比如这个短语“我有一个提供数据互操作性的解决方案。”这几乎没有意义，除非添加“在你的传感器和我的应用之间”。

水平和垂直领域的互操作性

在实践中，互操作性的复杂性在于它在物联网使用中，有多种组合。参看下图中一组物联网解决方案堆栈的框图：

一个物联网应用（App#1）可以通过中间件平台（MP#1）与相关的传感器（Sensor#1）进行通信。它还可能根据传感器数据，向执行器（Actuator#1）发送命令。在图示右侧的第二个物联网解决方案中，也有类似的布置。

现在我们假设有一种方法可以提高App#1的性能，通过使用与App#2相关的传感器数据。如果App#1和App#2之间存在互操作性，无论是通过外部数据交换（OTT互操作性），还是通过其各自的中间件平台之间的互操作性，这都是可能的。或者，App#1可能可以访问Sensor#2，因为它们各自的中间件平台之间具有互操作性。这种情况有助于我们考虑应用的水平互操作性，可以发现资源（例如，其他应用，其他中间件平台，其他传感器/执行器等），以识别其提供的服务（例如，发布的数据流，远程启动等），并通过事务（例如，发布/订阅解决方案堆栈数据，计费和结算的使用跟踪等）来使用这些服务。

在任意互操作性情况下，将会出现解决方案负责人发现更好的传感器（更高的性能），或者以更低的成本或更高的可靠性提供相同性能水平的传感器。App#1的负责人可能希望更换供应商，或使用多供应商解决方案，通过从供应商B处获得更好的产品来替换供应商A的Sensor#1。此示例提供了另一种技术和供应商互操作性的方案，价值堆栈的垂直领域。

迄今为止的讨论都是在双应用场景中的框图架构中。这种布置的物理实施，涉及来自不同供应商的硬件和软件。如果解决方案负责人希望更改网关，使用来自不同供应商的网关，那么会评估网关到中间件（和网关到传感器）的互操作性，以最大限度地减少自定义系统集成工作。这种互操作性类似于计算机连接到互联网，或能够国际漫游的手机。

在当今的云计算世界中，支持物理互操作性的一个例子可能涉及一个托管在Amazon Web Services上的应用（及其数据），和另一个托管在Microsoft Azure上的应用。这种布置是否提供了两个云基础设施服务之间的双向互操作性（包括通信，服务水平，数据语义等），还是取决于中间的解析？

物联网互操作性的战略意义

考虑到这些不同的方案，为什么企业对物联网互操作性进行战略思考是很重要的？至少有三个原因。首先，企业需要决定是投资单个或孤立应用。比如，他们是否只是想在一个工厂机器上安装状态监测应用，有着几十年的使用寿命？或者，他们希望使用相同的连接设备来支持其他应用，因此在未来可以支持多个潜在的跨部门或跨供应商应用？这关乎于产品发展的规划。

其次，物联网技术的用户是否将自己锁定在单一技术或单一供应商解决方案中？有一种方法可以解决这个困境。例如，许多电信运营商根据基于标准的互操作性，在其网络中部署多供应商基础设施。其他行业可以参考这个战略。工厂，办公室和家庭都拥有多个供应商的电器和设备，需要设备（终端执行器，传感器和网关）以及应用（未来的某个时刻）之间的互操作性。

第三，物联网技术的用户需要认识到技术上的不断演变，及其对解决方案堆栈的影响。虽然当前的互操作性讨论侧重于通信和硬件的兼容性，但是日后的解决方案会将互操作性挑战提升到价值层面上。

考虑涉及到多个互操作系统的场景，等同于交互数据片。无论数据格式是什么，这确保了系统之间的数据一致性。实际上，这可能来自于支持多个物联网应用的温度传感器的数字流；由于传感器和应用之间的语义互操作性，每个应用会将正确的含义应用于数字流（即，将它们识别为温度数据，无论是摄氏或华氏，而不需要将配置参数硬编码在应用中）。

技术演变具有长期的影响和投资意义。投资决策会有长期后果，以及期望在未来支持新的应用和业务模式中所获得的价值。