OTA更新：对云中服务器的要求

　　制造“联网汽车？现实情况是，汽车行业需要创建一个安全的管道，连接到汽车中的所有设备，并实现无线（OTA）更新。

　　为了使“互联汽车”成为现实，汽车行业需要创建一个安全的管道，连接到汽车中的所有设备，并实现无线（OTA）更新。如今，汽车制造商提供许多车型，这些车型具有各种各样的选项和设备包，可能需要更换或升级。对于现场车辆处理这些 OTA 更新的服务器有何影响？

　　为了发送正确的更新，服务器必须准确了解每辆车中所有设备的当前详细信息。每个型号或子型号可能有多种选项和设备包可供选择。其中一些选项或包装可能在生产过程的后期选择，甚至在区域分销或经销商库存中进行后期生产。即使在售后，设备也可以更换或升级，有时通过经销商网络，有时通过零件供应渠道（无论是通过独立机械师还是家庭机械师）。

　　所有这些都增加了汽车OTA环境的复杂性。考虑一个拥有三种不同型号汽车的汽车品牌。如果这些型号中的每一个都有五个不同的子模型，并且每个子模型都有十个不同的装饰包，那么我们突然面临 150 种不同的终端设备可能组合。

　　在表现出这种复杂程度的行业中，最好的方法是双向数据管道，该管道为每个单独的设备标准化协议和OTA相关行为。如果每个设备都可以报告其存在、正在运行的软件、状态和 OTA 相关功能，那么服务器就可以自动跟踪和区分各种车辆配置。

　　数据管道的 eSync 规范提供此功能。在 eSync 体系结构中，为每个设备编写一个代理。这些代理考虑了所有不同设备的特征，同时为数据管道实现了一组标准的行为和协议。任何两个设备可能具有不同的资源。例如，与安全带张紧器相比，ADAS高性能计算平台将具有更多的处理能力，更多的内存和更复杂的操作系统。使用标准协议，这两个设备的代理可以报告其不同的功能，使服务器能够使用不同的技术为这两个设备准备更新。

　　同样，每辆车中的客户端使用一组标准的行为和协议与云中的服务器相对应。标准客户端（车辆）行为之一是向服务器报告其所有代理的完整“树”，并在发生更改时更新服务器上的信息。

　　此过程完全自动化了最新车辆数据库的维护。在每时每刻，服务器在其车队中每辆车的每台设备上都有最新信息。维护数据库没有管理负担 - 如果每个客户端的配置或设备树发生更改，则每个客户端都会自行更新数据库。

　　汽车子系统的各种设备通常来自多个供应商，必须协同工作。标准化有助于确保所有设备都实施相同的 OTA 方法，以便可以顺利高效地访问、更新或回滚它们。标准化使认证机构具有一定程度的透明度，以帮助政府为多个汽车供应商实施的OTA机制的安全性带来秩序。如果每个供应商都追求自己专有的OTA方法，那么验证将成为一个非常困难的命题。

　　任何符合 eSync 标准的服务器都将符合标准功能行为和消息传递协议。在此级别提供标准化可实现跨公共云和私有云的可移植性，并促进在多个地理市场中实现一致的功能。eSync服务器已在Amazon AWS，百度，Microsoft Azure和腾讯公共云以及OEM专有服务器上实施。根据当地政策，在多个地理区域销售的汽车可以通过当地的服务器进行更新，即使服务器软件托管在不同的云上或来自不同的供应商。..。..只要它符合电子同步标准。

　　eSync 标准提供了一种分布式策略机制。可以在 eSync 服务器中为每个 OTA 活动设置策略，在每个软件组件包中设置策略以识别软件版本中与多个设备的依赖关系，eSync 客户端中的车辆策略以及驻留在该设备的 eSync 代理中的每个边缘 ECU 的策略。这种分布式策略可帮助 OEM 针对不同的地理位置和政府要求完善和定制其 OTA 机制。它甚至可以优雅地避免OEM的尴尬情况，当服务器驱动OTA更新活动与维修车库中通过诊断测试仪提供的更新冲突时。如果在车库中提供的更新是针对未进入 OTA 活动的特定修复完成的，则设备策略可以拒绝 OTA 更新活动，直到达到 ECU 中商店更新软件的到期日期。

　　审核编辑：郭婷