汽车行业正在接受制造互联汽车的想法。他们看到了利用来自车辆的遥测数据创造新的收入机会和建立更好的用户体验的机会。然而,实施可扩展以支持数百万辆汽车的互联汽车服务可能会带来一些挑战。
对于大多数互联汽车服务,需要汽车和云之间的双向通信。汽车将向云发送遥测数据,并启用预测性维护、辅助驾驶等应用。同样,汽车需要能够接收来自云的消息,以响应远程命令,如远程锁/解锁门和远程激活喇叭或灯。
实现车到云通信可以通过可扩展的 Web 技术(如 HTTP 请求)进行处理。但是,实现云到汽车通信需要系统中每辆车的静态 IP 地址。这不是一个合理的假设,因为汽车将通过蜂窝网络移动,因为每个设备没有单个 IP 地址。
除了双向消息传递挑战外,互联汽车服务还面临许多其他独特的技术挑战:
- 连接性通常不可靠,因为汽车可以通过网络盲点移动。重新连接到云的过程可能会导致响应时间变慢和消息丢失。
- 由于蜂窝网络性能,网络延迟可能再次成为问题。响应式用户体验必须能够处理网络延迟。
- 云平台需要能够向上和向下扩展,以支持数百万台车辆在不同时间点进行连接。
- 互联车辆需要在受信任的环境中运行,因此黑客无法控制汽车。
许多公司都尝试使用 HTTP 和 SMS 实现互联汽车服务。为了与汽车建立连接,云平台将向包含 URL 的车辆发送短信以启动 HTTP 请求/响应连接。但是,此模式已被证明不可靠,通常会导致用户体验缓慢。事实上,在某些情况下,从移动电话应用发送的远程命令最多需要 30 秒才能完成请求。从移动应用解锁车门的 30 秒不是汽车公司希望交付给客户的用户体验类型。
互联汽车的新架构
汽车公司、一级供应商和初创公司需要为其互联汽车服务找到新的架构风格。其中许多公司现在转向 MQTT 发布/订阅体系结构来实现其服务。MQTT 已成为连接设备和将数据从设备移动到云的实际 IoT 标准。
事实证明,MQTT 解决了创建可扩展和可靠的互联汽车服务的许多挑战,例如:
- MQTT 允许在汽车和云之间持续连接。当网络连接可用时,车辆将将数据发布到 MQTT 代理,并将几乎实时接收来自同一代理的订阅数据。如果网络连接不可用,车辆将等待网络可用,然后再尝试传输数据。当车辆脱机时,代理将缓冲数据,并且一旦车辆重新联机,它将立即提供数据。
- MQTT 实现三个服务级别的消息传递质量,包括最多一次、至少一次和一次传递。这使得创建以可靠方式运行的互联汽车服务成为可能
MQTT 入门
MQTT 解决了构建互联汽车服务的许多问题。宝马等汽车公司已经在使用MQTT为其汽车共享应用程序提供可靠的信息。对于那些想要开始使用MQTT的公司,有很多可用的信息和解决方案,包括开源经纪人HiveMQ,EclipseMosquitto和VerneMQ。将来,您应该期望大多数汽车使用 MQTT 发送其连接的数据。
