汽车行业正在接受发明真正联网汽车的想法。他们看到了利用从车辆收集的遥测数据来创造新的收入机会和建立更强大的客户体验的机会和好处。然而，成功推出可扩展以支持远距离和各种环境条件下的数百万辆汽车的联网汽车服务可能会带来一些严峻的挑战。
对于大多数联网汽车服务，汽车和云之间的双向通信是必需的，尽管一些边缘处理可以使联网汽车更加独立于云。连接车辆将遥测数据发送到云端，并启用预测性维护、辅助驾驶、应急响应等应用。同样，车辆需要能够从云端接收消息以响应远程命令，如远程门锁和解锁、远程激活喇叭或灯，改变交通环境等。
实现汽车到云的通信可以使用标准的 Web 消息传递协议（如 HTTP）来处理。然而，考虑到车辆的 IP 地址在从蜂窝网络转移到网络时会不稳定，因此云到汽车的通信可能需要不同类型的通信系统。
除了双向消息传递挑战之外，联网汽车服务还面临许多其他独特的技术挑战：
连接性通常不可靠，因为汽车可以通过网络盲点。与云重新连接的过程可能会导致响应时间变慢和消息丢失。
由于蜂窝网络性能，网络延迟可能再次成为问题。对于响应式用户体验，汽车必须能够处理网络延迟。
云平台需要能够向上和向下扩展，以支持在不同时间点连接的数百万辆汽车。
联网车辆需要在受信任的环境中运行，这样黑客就无法控制汽车。
许多公司已尝试使用 HTTP 和 SMS 来实施联网汽车服务。为了与汽车建立连接，云平台会向车辆发送一条短信，其中包含一个用于发起 HTTP 请求/响应连接的 URL。然而，这种模式已被证明是不可靠的，并且通常会导致用户体验缓慢。在某些情况下，从手机应用程序发送的远程命令最多需要 30 秒才能完成请求。从移动应用程序解锁车门 30 秒并不是汽车公司希望为客户提供的用户体验类型。
MQTT 的发布/订阅协议旨在解决联网汽车服务的挑战，非常适合在汽车和云平台之间移动数据。
事实证明，MQTT 解决了创建可扩展且可靠的联网汽车服务的许多挑战，例如：
MQTT 允许在汽车和云之间建立持久的永远在线连接。当网络连接可用时，车辆将向 MQTT 代理发布数据，并将近乎实时地从同一代理接收订阅数据。如果网络连接不可用，车辆将等到网络可用后再尝试传输数据。当车辆离线时，broker 会缓存数据，并会在车辆重新上线后立即传送数据。
MQTT 实现了三种消息传递服务质量级别：最多一次传递、至少一次传递和恰好一次传递。这使得创建以可靠方式运行的联网汽车服务成为可能。MQTT 的高级消息保留策略和离线消息队列对于适应网络延迟和不可靠的移动网络至关重要。
无法通过 Internet 寻址运行 MQTT 客户端的汽车。运行在每辆车上的 MQTT 客户端负责使用 TLS 与云中的 MQTT 代理建立安全的持久 TCP 连接。这意味着汽车上没有公开的公共互联网端点，因此没有人可以直接连接到汽车。这使得汽车几乎不可能在互联网上受到黑客的直接攻击。
MQTT 代理可以部署到在私有或公共云基础架构上运行的集群节点。这允许代理根据尝试连接的车辆数量扩大和缩小规模。