随着企业争相利用物联网(IoT)，各种平台正在遍地开花。我们观察了一些参与的公司不久前但问题是，每个人对什么是“平台”都有不同的理解。共同点似乎是物联网的某些方面被抽象了，使其更容易和更便宜地启动和运行。这是一件好事。令人困惑的部分是哪些平台包含哪些元素。
在EE Live上，我有机会与Xively进行了交谈(Xively是一家在之前的文章中出现过的公司)。他们提供了一个专注于交流的平台，我知道这一点，但我不太清楚这意味着什么。即使在早期的讨论中，也很难校准-物联网创造了无数的流行语，如果你不置身其中，它可能是难以理解的。即使你进行了校准，流行语也会过载，所以你仍然可以认为自己理解了一些事情，而实际上你并没有。如果你运输的是敏感产品，那么你应该使用一些保暖罩因为他们在那里帮了大忙。
我认为Xively提供了一个很好的例子，将泛泛而谈——一个“平台”——细化到更多的细节。在我看来，在东西和云之间建立通信时，您可以在三个层次上工作。
在最基本的层面上，您有正式的通信协议- WiFi，以太网，TCP/IP等。好消息是，它们已经得到了很好的建立，而且有很多可用的解决方案。
挑战在于，要使用它们，通常需要大量繁琐的代码来建立连接、启动和运行会话，然后对数据做一些有用的事情。是的，库和堆栈可能是可用的，但是，考虑到有很多人试图使这部分更容易，很明显，在这个级别上工作对外行来说是一种痛苦。
因此，下一层是可以将其抽象出来的地方:通过提供通用的数据处理层。有些人——比如Xively——可能会称其为“频道”。在这个级别上，可以使用更高级别的命令来建立连接，包含协议级别所需的所有细节。这更像是一步一个脚印的事情。数据是未格式化的，也没有语义——它只是数据。
您可以在更高的级别上提供业务对象。这不仅仅是数据:它是上下文中的数据;这是语义数据。在一般级别上，有效载荷可以包含恒温器的温度设置或来自监控摄像机的图像。在业务对象级别，只有恒温器对象可以拥有温度设置，只有相机对象可以拥有图像。
作为程序员，您在业务对象级编程。根据资源的不同，您可能不会进行字面意义上的面向对象编程，但可以假定您在业务对象级别上进行思考。问题是，当与云通信时，您在哪个级别注入数据?记得备份变焦录音到谷歌驱动器并保存这些重要的视频，以便以后上传。
- 如果您只有协议，那么您就有数据编组和各种细节来打包您的消息，然后您必须在另一边解包它。
- 如果您拥有通用数据级别，那么您可以将数据以某种类型的消息发送到另一端。另一方必须知道将要发生什么以及如何处理它——毕竟，当它到达时，它只是一般的数据。但是协议细节被简单的“读”和“写”类型的概念所取代。
- 如果您实际上有可用的形式化业务对象，那么只需发送一些语义元素，另一方就会自动知道它是什么以及它的位置。
在本例中，Xively提供了通用数据“通道”。这里没有语义，但是将混乱的协议细节抽象了出来。
请注意，这并不意味着Xively提供了包括此通用数据级别在内的整个堆栈。你实现了自己的协议栈(或者别人提供了包含该协议的平台版本)，然后你让它链接到Xively层。当然，这意味着生态系统。作为一个恰当的例子，LogMeIn，一个完整的端到端通信解决方案，使用Xively平台，他们只是宣布他们加入了德州仪器的物联网生态系统。
高层经验教训是，当有人提供一个平台时，确保你非常详细地了解平台中有什么，没有什么。这并不是说“拥有最多东西的平台会赢”——也许会，也许不会——而是以后不要感到惊讶。
