汽车行业正在接受构建联网汽车的想法。他们看到了利用车辆遥测数据创造新收入机会并打造更好用户体验的机会。然而，实施可扩展以支持数百万辆汽车的联网汽车服务可能会带来一些挑战。

对于大多数联网汽车服务，汽车和云之间需要进行双向通信。汽车将遥测数据发送到云端，并启用预测性维护、辅助驾驶等应用程序。同样，汽车需要能够从云端接收消息以响应远程命令，例如远程锁/解锁车门和远程激活喇叭或灯。

实现汽车到云的通信可以通过可扩展的 Web 技术（例如 HTTP 请求）来处理。然而，实现云到汽车通信需要系统中每辆车都有静态 IP 地址。这不是一个合理的假设，因为汽车将通过蜂窝网络移动，而每个设备没有单一的 IP 地址。

除了双向消息传递挑战之外，联网汽车服务还面临许多其他独特的技术挑战：

连接通常不可靠，因为汽车可以穿过网络盲点。重新连接云的过程可能会导致响应时间变慢和消息丢失。
由于蜂窝网络性能的原因，网络延迟可能再次成为一个问题。响应式用户体验必须能够处理网络延迟。
云平台需要能够扩展和缩小，以支持数百万辆车辆在不同时间点连接。
联网车辆需要在可信环境中运行，这样黑客就无法控制汽车。
许多公司尝试使用 HTTP 和 SMS 实施联网汽车服务。为了与汽车建立连接，云平台将向车辆发送一条短信，其中包含用于发起 HTTP 请求/响应连接的 URL。然而，这种模式已被证明是不可靠的，通常会导致用户体验缓慢。事实上，在某些情况下，从手机应用程序发送的远程命令最多需要 30 秒才能完成请求。通过移动应用程序 30 秒解锁车门并不是汽车公司希望为客户提供的用户体验类型。

联网汽车的新架构
汽车公司、一级供应商和初创公司需要为其互联汽车服务找到一种新的架构风格。许多这样的公司现在正在转向 MQTT 发布/订阅架构来实施他们的服务。MQTT 已成为连接设备和将数据从设备移动到云端的事实上的物联网标准。

事实证明，MQTT 解决了创建可扩展且可靠的互联汽车服务的许多挑战，例如：

MQTT 允许汽车和云之间建立持久且始终在线的连接。当网络连接可用时，车辆将向 MQTT 代理发布数据，并近乎实时地从同一代理接收订阅的数据。如果网络连接不可用，车辆将等到网络可用后再尝试传输数据。当车辆离线时，代理将缓冲数据，一旦车辆重新上线，它就会立即传递数据。
MQTT 实现了三种消息传送服务质量级别，包括最多一次、至少一次和恰好一次传送。这使得创建以可靠方式运行的联网汽车服务成为可能。MQTT 的高级消息保留策略和离线消息队列对于适应网络延迟和不可靠的移动网络至关重要。
运行 MQTT 客户端的汽车无法通过互联网进行寻址。每辆车上运行的 MQTT 客户端负责使用 TLS 与云中的 MQTT 代理建立安全的持久 TCP 连接。这意味着汽车上没有暴露公共互联网端点，因此没有人可以直接连接到汽车。这使得汽车几乎不可能受到互联网上黑客的直接攻击。
MQTT 代理可以部署到在私有云或公共云基础设施上运行的集群节点。这使得代理可以根据尝试连接的车辆数量来扩大和缩小规模。
MQTT 入门
MQTT 解决了构建互联汽车服务的许多问题。BMW等汽车公司已经在使用 MQTT 为其汽车共享应用程序提供可靠的消息传递。对于那些想要开始使用 MQTT 的公司来说，有很多可用的信息和解决方案，包括开源代理HiveMQ、Eclipse Mosquitto和VerneMQ。将来，您应该期望大多数汽车都将使用 MQTT 发送连接数据。