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

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

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

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

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

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

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

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

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

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

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