进入21世纪以后物联网逐渐扮演者重要的角色，物联网 （IoT）推动嵌入式控制向前所未有的智能水平发展。在独立使用设备之处，物联网将它们集成至一个由多个子系统组成的系统中。这使得设备间能够相互协作并与其他服务进行交互，从而提供更出色的性能、响应能力和正常运行时间。

对于由应用提供的所有物联网设备的数据流，用户均可利用云的强大计算能力，让机器学习、数据挖掘和其他技术对这些数据流进行处理。同时，这些物联网设备也无需专门针对应用进行设计。基于云的系统可以利用 Spark 和 Hadoop 等数据整理技术对不同来源的实时信息和历史信息进行整合，可以实现跨多个来源的关联作业，同时在实现过程中获得有价值的信息。虽然物联网具备一定的处理能力，但也会不可避免的遇到各种复杂状况。

物联网应用交付的一个关键问题是每个解决方案的组成部分都很多样性。物联网应用需要获取来自不同类型传感器的读数，例如温度、运动和空气质量。即使是同类型的传感器读数，数据也可能采集自不同制造商提供的设备，或者来自非物联网设计的旧硬件。

以监测酒店每个房间内温度的物联网项目为例。每个房间可以有三个传感器，且每个传感器都能监测温度。靠门的传感器可以将其温度传感器作为火警报警器模块的一部分，另一个靠近床的传感器可以与客房空调控制相关联，而浴室中的传感器可以作为物联网升级部分的专用装置安装。

对于那些从每种类型设备处获取读数的软件，需要考虑每个传感器的校准方法及获得数据的方式。一些设备可以依据超出编程阈值的条件变化或通过基于云的应用按需定期发送数据。同时，它们可能使用不同的网络连接，如使用有线网络，而有的则使用蓝牙或Zigbee等无线网络。此时，应用需要考虑这种可变化性。但问题远却远不止如此。

功耗是许多物联网设备要解决的首要问题。保持较长电池使用寿命的最常用方法是最小化无线通信及核心微处理器等高功耗系统的活动。这些子系统在系统的大部分生命周期都保持低功耗睡眠状态。它们会在短时间内醒来，并在再次睡眠前处理任务。最终减小运作周期。也许系统生命周期中只有不到1%的时间处于完全清醒和高功耗状态。在剩余的99%的时间内，仅对维持系统状态所需的系统（例如实时时钟）进行供电。采用这样的设计，物联网节点可在单次充电后使用数年。

现在，许多微控制器 （MCU） 都集成了硬件状态机。这样一来，可以通过实时时钟触发来定期唤醒重要的传感器，且可在不唤醒主机微处理器的情况下获取读数。在微处理器被唤醒并执行处理操作之前，某些系统可以采用一组预定读数。其他系统也可将阈值编程至传感器逻辑中，以便立即对较大偏差做出反应。

在云中运行的控制应用可能会从设备处请求需要的数据，或通过向设备发送命令来更改状态。但为了确保低占空比需求，设备不会在短时间内响应。因此当命令发出时，设备仍将处于低功耗状态。该应用需要用逻辑思维来确保其对设备状态的理解与现实保持一致。

在物联网初始阶段，集成商发现他们必须使用自定义协议或远程过程调用 （RPC） 技术来构建自己的云集成软件基础设施。通常，他们会在专用设施中使用自己的数据中心或租用刀片式服务器，并会从连接的嵌入式设备中接收数据，将信息推送到中央数据库并运行向用户呈现数据和执行模式分析的应用。

集成商要确保故障恢复能力和高可用性，并处理未能永久连接到设备的复杂环境。实现这一目标的一种方法则是使用设备影子概念。这些设备影子指的是在云端存储的文档，可以缓存有关设备状态（自上次报告后）和任何待定更改的信息。

虽然应用可以自己管理设备影子，但如果将其转移到可跨多种类型的设备提供标准化接口的服务层，则可更轻松地管理该项任务。目前，这是Amazon Web Services、IBM Watson IoT和 Google Cloud 等云基础设施产品提供处理的众多功能之一。

云基础设施平台执行的另一项服务是协议映射。云是围绕TCP/IP 协议，以及其能够承载服务的广泛使用而发展起来的。虽然许多基于云的服务所用的超文本传输协议 （HTTP） 是一种无状态协议，但由于TCP的广泛支持，该协议可运行在面向状态的TCP 层之上。但只有少数物联网设备具有可实现完整 TCP/IP 堆栈的资源，进而实现与云应用直接通信。由互联网工程任务组 （IETF）请求定义的受限应用协议 （CoAP） 简化了 HTTP，使其与资源受限设备更加兼容，并消除了使用 TCP 层的需求。

CoAP采用 4 字节报头和紧凑编码，能支持协议的数据包长度比通常的由骨干以太网连接所提供的数据包长度长。常见的替代CoAP方案是 IBM 开发的消息队列遥测传输 （MQTT） 协议，该协议具备适合更多物联网设备的特性。该协议可在各种数据包格式上运行，例如蓝牙、Zigbee以及 TCP/IP。与传统 HTTP Web 服务的客户端服务器模式相比，MQTT 支持发布订阅模式。该模式具有尽量减少单个物联网设备请求的优点。