汽车软件自动更新系统设计

最新推荐文章于 2025-12-04 16:24:28 发布

原创最新推荐文章于 2025-12-04 16:24:28 发布 · 830 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#软件更新 #系统工程 #汽车电子 #自动化 #安全架构

汽车电子系统自动化软件更新的系统工程

摘要

在传统的汽车电子设计中，软件更新一直是一种面向组件的手动过程，而不是适合自动化的系统化内置功能。近年来，随着车辆中的软件内容不断增加，更频繁地更新车辆软件已成为一种必要。此外，软件更新的其他属性，例如及时交付与安全相关的更新、希望通过软件更新添加功能、控制软件更新成本等，都要求采用系统工程化设计，而非面向组件的方法。由于汽车领域使用了多种出行方式（内燃机、混合动力、电池等）以及多种功能领域（信息娱乐、安全性、出行方式、远程信息处理、ADAS（高级驾驶辅助服务）、自动驾驶等），为了控制未来软件的整体成本，在这种多样化的环境中，引入自动化对软件更新过程是有益的。促进自动化引入的一种方法是利用系统化架构。由于用于更新软件的系统本身也需要被更新，因此稳定的接口设计非常重要。

本文回顾了汽车领域软件更新系统架构的现状和先进水平，并回顾了个人设备领域当前的软件更新架构。通过建立这些架构的模型来比较系统架构。为了综合出合适的系统架构，确立了相关系统属性。基于所开发的系统属性，综合出一个软件更新系统的模型。将所开发的模型与其他模型进行比较。最后，讨论了评估有效性的措施。

引言

历史上，汽车电子技术的发展曾落后于军事和航空航天电子技术。然而，现代汽车系统在复杂性上已不再低于现代武器或航天系统。随着汽车系统中的功能越来越多地依赖电子技术，汽车系统中软件的使用正以指数级速度增长。例如，某原始设备制造商（OEM）报告称（2016年），其最新的豪华车型将包含超过一亿两千万行软件代码。此外，随着汽车系统日益以软件为核心，修正错误、增强现有功能以及提供新的基于软件的功能的需求也变得越来越普遍。原始设备制造商（OEM）已经从2015年和2016年开始通过软件更新方法添加驾驶员辅助功能。汽车系统将使用更多的软件，并且车辆软件在其生命周期内需要持续进行更新。传统的汽车电子设计和软件架构框架是否已为这一挑战做好准备？

汽车电子系统传统上被设计为嵌入式分布式系统，主要在当地子网中进行广播数据传输。这些系统由通过多种类型的通信网络连接的众多电子控制单元（ECUs）组成。传统上，汽车原始设备制造商利用供应商来设计和制造这些电子控制单元（ECU），然后负责将其集成。在此框架下，更新组件软件需要连接外部工具并更新目标电子控制单元（ECU）。这种方法存在以下问题并将持续影响未来：

每个电子控制单元（ECU）的软件更新从供应商和性能角度来看都被视为独立事件——将所有软件数据集更新到目标车辆ECU所需的时间对任何单一供应商而言都不是关键参数。
多个电子控制单元（ECU）的同步更新并非被设计实现，而是作为各个电子控制单元（ECU）更新模型的副产品而实现的，例如，用于同时更新多个电子控制单元（ECU）所需的通信网络带宽不受任何单一供应商控制。
电子控制单元（ECU）之间的软件更新依赖关系通常并不明确。维修站的技术人员可以通过手动错误检测方法来弥补隐含的依赖关系，并在必要时随后安装额外的软件更新。
有时，在软件更新后，需要手动操作连接到电子控制单元的传感器或执行器。

如果我们考虑到仅在美国每年就有约1700万辆车辆售出，且每辆车每年都需要某种形式的软件更新，那么使用传统框架和架构（主要是手动流程）进行更新所带来的负担是巨大的。随着未来软件更新事件的增加，有机会通过自动化和更优的系统设计来管理这一过程。

此外，最近一方面关注防止对电子系统的未经授权的访问，另一方面引入通过自动化更改软件的能力，这带来了重大的设计挑战。用于更新软件的系统必须是完全安全的，并且不增加任何漏洞。相比基于组件的方法，系统化方法更有可能实现这一目标。

使用软件更新来纠正错误的能力使得在产品交付后规划修复小错误成为可能。从相反的角度来看，在汽车领域，产品在交付前会经过充分验证，并在产品发布前解决所有缺陷。那么，软件更新功能是否为企业提供了价值？随着软件变得越来越复杂，且功能的使用方式超出了设计者的预期，有时在产品交付后仍会出现错误。通过自动化方式进行软件更新的能力，能够以具有成本效益的方式纠正这些错误，同时也为将来增加更多功能提供了可能性。

本文的结构如下：在“汽车实践与模型现状”一节中，回顾了传统和现代车辆软件更新系统。在接下来的“先进技术和模型”一节中，描述了个人设备领域所采用的软件更新架构。经过分析可知，目前个人设备领域所使用的现有软件更新系统架构并不完全适用于汽车领域的当前业务驱动因素和商业环境。在“自动软件更新所需系统属性”一节中，制定了一组系统属性，以满足业务驱动因素和当前业务条件。随后构建了一个模型，使得此前提出的所有系统属性都能在该模型中得以实现。在“自动软件更新所需的软件架构模型”一节中，提出了一种软件架构，使得能够对软件更新系统本身进行软件更新。在结论部分，对所构建的所有模型进行了比较，并提出了评估建议。

汽车实践与模型现状

车辆主要在OEM装配厂停车场完成生产后，或在维修店进行维护服务时进行更新。如前所述，传统的汽车软件更新方法是通过将外部工具连接到车辆的数据链路连接器（DLC），并按照外部工具用户界面上的手动操作指令来实现软件更新[4]。更新时间取决于更新的大小、需要更新的模块数量、多个模块安装顺序的依赖关系以及是否需要遵循一定数量的手动操作指令。由于车内大多数电子控制单元（ECU）都连接到DLC，因此可以使用标准的CAN总线诊断协议来更新大多数电子控制单元（ECU）的软件。此外，在少量更新的情况下，手动流程不会造成过重的负担。

最早的自动软件更新形式已被用于导航系统以更新地图，以及用于远程信息处理系统以更新远程信息处理软件[1]。推动自动化的首要动力是提供最新的地图，而无需前往维修店，并跟上蜂窝领域的变更。在这些情况下，只要待更新的目标组件能够通过无线方式直接从车辆外部访问，且待更新的组件不会干扰主要的汽车功能，仍可采用独立方法。

无线数据下载自动化方法的一个障碍是无线通道的成本。一种方法是减小更新负载的大小。过去采用过两种相互竞争的方法：更新包压缩，以及使用版本差异的更新包减小。如果预期的更新是增量式而非结构性的，则使用差异方法进行更新包减小效果更好。根据完整镜像的可压缩程度，压缩会带来优势。在某些情况下，结合使用这两种技术可以实现更小的负载。对于较大的变更，差异方法开始导致更长的安装时间。某些镜像（如地图）难以压缩。

最近，一家原始设备制造商将软件更新视为重要的业务驱动力，并在初始系统设计中纳入了自动更新车辆软件的能力。随后，一项涉及制动、转向和悬挂的功能增强通过远程服务器经无线通道发送的软件更新，在客户现场完成部署，[1]。在此案例中，该系统从零开始设计，并利用了仅电池供电车辆的用例优势——每日充电时间（此时车辆未使用）。为此案例实现的系统架构，为其他类型动力总成的车辆提供了未来控制软件更新负担的机会。

软件更新系统车型

先进系统可以建模为“传统”或“现代”，如下所述。

示意图0

在“传统”系统架构中，如图2所示，车辆通过有线网络连接。编程工具在手动连接并启动后，将目标设备置于编程模式，并开始分段传输更新包。该更新包此前已根据特定车辆配置可用的有效更新从后台服务器获取。车辆位于维修店或装配厂区停车场——不允许客户参与。

在“现代”系统架构中，车辆与无线网络相连。存在一个适用于特定车辆的更新包，该更新包被下载并存储在车辆中，或带有更新包的存储设备连接到车辆，然后车载编程工具更新一个或多个电子控制单元（ECU）。对于地图更新，车辆可以处于移动状态。客户只需极少参与。如果正在更新与移动性相关的功能，则车辆将变为不可移动状态。如图2所示场景中，所需的架构考虑因素较少，原因如下：1）自动更新仅限于少数电子控制单元（ECU），2）相互依赖的电子控制单元不在范围内——例外情况[1], ，3）车辆无法使用的时间长短并非重要标准，4）企业级系统扩展是一项挑战。同时，存储多种配置（各种选装内容、车型年份等）以随时提供服务并未被考虑在内。此外，软件更新用例仅从车辆组件更新的角度出发，未在设计上考虑降低软件更新的企业成本。

示意图1

示意图2

示意图3

先进技术和模型

个人设备（如手机、平板电脑、笔记本电脑和台式机）中的软件更新已被客户接受为这些设备的“功能”，因为该功能可用于提供新功能、配置新设备、应对安全相关问题等。这些设备与汽车系统之间存在一些关键的架构差异点：

首先，这些设备被视为单一终端。终端上可能运行着多个外设或多个应用程序，但更新包可以与单个终端相关联。

其次，这些设备在通电时会连接到互联网，而更新通常使用成本敏感的带宽。例如，规则可以是：如果平板电脑同时连接了蜂窝网络和Wi-Fi，则使用Wi-Fi（或有线互联网连接）进行更新。

第三，由于消费者将这些设备视为带有软件的产品，因此提示客户接受更新并同意暂时无法使用，并未引起无法容忍的不满。甚至最近为消费者利益而推出的“紧急安全补丁”也可选择启用。

如果这些设备未被使用，它们通常仍处于通电状态。因此，很容易找到设备空闲且适合进行更新的时间段。

利用这些方面，最近大多数面向个人设备的框架都采用了将所有终端与主镜像同步的概念——这是移动设备管理套件的一个方面。当需要向多个终端点交付更新时，服务器会启动一个同步协议，该协议不仅尝试整体更新终端设备，还会记录终端点最新的配置，以满足其他业务需求。

从汽车行业的角度来看，这一结果是可取的，但该情境并不完全符合传统系统架构：

架构在一次会话中更新整个车辆是一项挑战，因为电池充电状态和更新时间是主要限制因素。
车辆可能没有足够的内存来同时存储所有组件的更新包。
由于选装内容导致的车辆变体差异涉及大量变体，后端需要大量的存储空间。
车辆生命周期比个人设备长一个数量级，导致软件更新所需支持的车辆代际数量大幅增加。
由于车辆不被视为“带有软件的设备”，客户对更新的接受度是一个挑战，这可能导致更新活动持续较长时间。

自动软件更新所需系统属性

为了实现有效的系统设计，本节讨论了相关属性。如前所述，汽车电子系统是通过多条总线连接的多个电子元件组成的分布式系统。以下介绍的各种属性有助于实现软件更新的自动化。

安全性

在更新车辆软件期间，必须确保安全。在最严格的情况下，要求车辆不可移动。该过程的某些初步阶段可以在车辆可移动时完成，但安装阶段则要求车辆不可移动。

连接性

显然，自动更新需要具备在无需人工干预的情况下将企业与车辆连接的能力。此外，车辆中的每个组件都需要能够通过外部有线连接器或无线连接进行连接。然而，这并非如此简单直接。如果考虑安全因素，则更安全的做法是实现最小访问。为了防止恶意连接尝试，连接接口必须提供防火墙功能。在软件更新过程中，目标设备必须能够确认接收到的命令和更新包来自预期的源，并且在传输过程中未被篡改。因此，架构需要具备不同级别的完整性与身份验证能力，以确保组件不会被破坏。

此外，每个组件都有可能是一个定制设计的电子模块，以下列出了一些挑战及潜在解决方案。

CAN连接性

CAN架构的多主控和广播特性，使得在接收端实现认证更具挑战性。在组件层面，每个电子控制单元可以通过PKI方法将自身认证为有效实体，以注册到车载主控组件。但这会给较小的组件带来较大负担。传统上Seed/Key算法被用于此目的。新型架构正在使用基于“密钥”的消息认证，涉及专用安全硬件附件。

标准CAN协议还限制了在同一子网内对多个组件进行并行软件更新。涉及交错的特殊仲裁方案需要在诊断模式下采用，以允许多个组件从“客户端”接收更新包的片段，同时“服务器”能够向“客户端”发送下一片段的状态信息，从而避免诊断会话超时。

最近，采用冗余内存以实现更快的更新和回滚能力的想法正逐渐被接受。冗余内在多种车辆模式下进行更新。然而，必须考虑CAN网络带宽，以确保编程通信不会干扰功能通信。对于这种情况，可考虑使用具有更高带宽的CAN总线。

以太网连接性

随着汽车部件功能的不断增强，为实现更高性能，以太网总线的使用正被越来越多地考虑。更高的带宽不仅有助于实现更快的更新，而且IT领域的工具和设计（例如安全（完整性和真实性）、网络传输等）也正在被复用，以减少完成一个可行设计所需的工作量。

其他连接性

许多组件通过其他串行数据总线（如LIN、SPI等）集成和/或控制外设。通常，可以通过将这些外设的配置包作为父级的一个特殊分区来对其进行配置组件更新。父组件可以在每次更新时配置外设，或者检测外设是否与父级配置兼容，并尝试配置外设。

此外，某些车辆的架构可能导致更新某个组件时，会干扰更新工具与位于该组件下游的其他组件之间的通信能力。这要求更新工具必须实现一种机制，能够按照与车辆架构兼容的可接受顺序来安排更新的次序。

匹配连接带宽

在软件更新领域，早期的经验之一是：更新组件所需的时间更多地取决于将更新包从汽车内部传输到目标组件的时间，而不是将数据写入内存所需的时间。连接组件与外部或无线连接器的数据总线的带宽需要与组件的内存大小相匹配。

安全

由于主要目标是消除人工干预并实现自动化，因此任何未经适当认证的实体都绝对不能更改任何组件中的软件。来自车辆的经过身份验证的外部连接、经过身份验证的选择性内部连接以及更新包的防篡改措施至关重要。大多数设计都包含对远程连接的加密，以防止中间人篡改。

本地存储

在传统的电子控制单元设计中，编程工具存储更新包，并将其分段传输到目标电子控制单元进行编程，因此无需在车辆中存储更新包。在自动化设计中，通过无线通道实现车辆与远程源之间的连接性。为了确保完整更新包的可用性，必须将其存储在车辆中。因此，需要配备能够存储一个或多个电子控制单元（ECU）更新镜像的存储设备。

车内提示与客户交互

更新过程需要向客户告知将要进行的变更：更新所需时间、更新原因、更新所新增的功能（如有）等。同时还需要向客户传达更新状态、更新进程的进展情况，以及在更新完成时进行通知等。此属性要求具备某种向客户指示的方式。

更新过程还需要与客户交互，并引导客户完成该过程的所有必要步骤，将需要一些操作，例如停放在安全可靠的位置、提供更新确认等。此属性需要通过某种方式与客户进行交互。

高成功率

在自动软件更新场景中，重点是减少手动流程。因此，自动软件更新过程的成功率必须非常高。如果自动更新未成功，则需要人工干预。目前，成功率通过“每千次中有x个”之类的不符合项度量来测量，并带有置信因子。为了规避返工带来的人工成本，该测量值需要提高一个或两个数量级。

重复性

由于原始设备制造商希望更新车载的所有组件，因此至少需要定义一个流程，用于准备更新包、将更新包交付到正确的目标，并记录安装成功情况。作为一个企业级流程，该流程应适用于所有车型和车型年份，并保持一致的运行方式。该流程的治理包括监控流程、衡量成功因素以及调整流程以实现改进。

电池充电状态

软件更新过程所需时间与电池充电状态密切相关。在软件更新过程结束后，车辆应能够正常操作。因此，必须考虑软件更新过程中对电池的使用，并施加适当的限制。在此背景下，电池充电状态测量和指示功能至关重要。

系统架构建议模型

建议的系统架构模型是通过将“现代”版本的模型与“自动软件更新所需系统属性”一节中描述的系统属性相结合而得出的。以下是总结的增强内容。

整体安全性经过设计，可防护所有自动软件更新中的已知和潜在威胁。
提供使用多个无线通道以及有线接口的连接性（互联网）。由于预期在一次会话中更新多个车辆ECU，需预先确定相对于车辆电池充电状态的总线带宽利用率的可行性。
由于汽车系统具有较长的生命周期，因此在设计中包含了更新安全系统的能力。
据认识到，某些电子控制单元（ECU）可能过大，无法通过无线传输进行更新，因此设计中包含了使用有线连接更新部分电子控制单元（ECU）的方案。
车载提示及与客户就即将进行的软件更新进行交互也已被明确识别。
为了实现自动化，每个电子控制单元（ECU）的故障发生率需以每数千次为基准进行测量，而非当前按每千次尝试测量的做法。
每个电子控制单元（ECU）都必须符合某些标准设计和实现细节，以便软件更新在多个车辆型号以及同一车辆型号的不同配置中都能以相同的方式工作。如果实现能够由一个软件源代码库来控制，则重复性将更高。
由于未来车辆将支持远程连接，因此必须考虑与其他连接功能相关的逻辑干扰。

自动软件更新所需的软件架构模型

根据“自动软件更新所需系统属性”一节中描述的系统属性，可以结合各种业务驱动因素来组织软件架构和软件元素。然而，由于车辆的生命周期通常约为十年，因此软件更新系统本身也必须是可更新的。实现这一目标的系统化方法是拥有一组尽可能解耦的定义明确的软件元素，并且其接口经过精心设计，确保不会随时间发生变化。这种方法有助于避免某个软件元素的变更影响到整个系统。在此上下文中，软件元素可以映射到一个或多个“对象”或“服务”。图7所示的架构展示了其中一种这种组织方式，并确定了在实现前述系统属性时至关重要的基于软件的要素。

该架构可分为两大类：车载元素和远程元素。每个软件元素均从应用层面描述其接口和功能。车载无线服务是一种抽象，用于在企业与车辆之间针对各种实际无线类型（蜂窝网络、Wi-Fi等）实现远程连接及安全相关服务的中介。

以下是车载元素

后台接口（下载管理器）
功能：The back office interface 是架构中的关键组件。它监听来自企业的软件更新相关命令，向企业提供状态信息，并在需要时从指定服务器下载文件。它了解车辆状态（包括连接性），维护车辆状态和软件更新状态信息，并与无状态企业服务器进行交互。它使用本地存储安全地保存已下载的文件，并实现/加强无线连接的安全性。
接口：基本接口包括：a) 与企业服务器的命令/状态接口，b) 车辆配置信息请求/响应，c) 远程文件下载请求/暂停/恢复，d) 本地文件存储/检索，e) 无线连接，f) 车辆数据服务以了解车辆状态。
安全：至少需要与远程实体进行认证。建议使用加密。

无线连接服务能力
功能：无线连接服务为车辆提供无线连接能力——抽象出长距离或短距离物理层。它包括安全功能，以将车辆与未经认证的连接隔离。这还可用于监控网络流量，以分配连接成本。
接口：基本接口包括：a) 车辆数据服务以了解车辆状态，b) 长距离和短距离无线物理层抽象，c) 企业安全服务器用于初始化/续订证书及其他必要事项。
安全：车辆外部接口至少需要通过接入点进行认证。对于蜂窝服务，服务订阅流程包含认证和授权。对于车辆内部，必须对车辆数据服务实施某种形式的访问控制。该访问控制可通过多种方式实现，例如防火墙、授权或认证与加密。

车辆数据接口
功能：车辆数据接口是解耦各种组件的关键。它覆盖车载网络中的低速（CAN）和高速（MOST/以太网/CAN FD等）。在应用层面，可采用无需中间代理模型的动态连接的发布/订阅技术，以隔离各种功能元素。此外，与安全相关的功能（如发送者认证、加密消息和重放攻击防护）应针对特定数据元素可配置。

Vehicle State Manager Capability
功能：允许车辆用户更改与车辆自动更新软件相关的出行方式、正在使用的电池、连接性等车辆状态。传统状态管理器需要为自动化增强，增加安全地改变状态的能力，以实现软件更新所需条件，例如车辆静止、充足的充电状态、互联网连接等。
接口：必须具备查询当前状态和请求状态变更的能力，例如建立连接等。
安全：对于车辆内部，使用认证和授权来实现车辆状态管理器的访问控制至关重要。

Display Service Capability
功能：启动下载更新包、提供下载状态、启动安装过程以及提供安装状态，这些功能最适合通过显示屏和按钮/触摸控制来实现。为了实现各种用户界面的解耦，抽象化显示服务至关重要。
接口：能够指示客户准备车辆、获得自动更新的许可以及提供持续状态是关键接口元素。
安全：需要基于状态管理器状态的访问控制和授权，以确保与软件更新相关的交互不会由恶意行为者发起或意外启动。

更新安装管理器
功能：更新安装管理器软件元素负责管理各种端到端事务和本地服务，例如向远程服务器提供车辆配置状态、管理更新包的下载、确定车辆状态以及启动与用户的交互，当所有条件满足时，启动车辆更新。实际更新过程可能根据实现方式使用不同类型的库。
接口：实现远程服务器通信、下载更新包和安装服务的稳定接口至关重要。由于安装过程在很大程度上依赖于具体实现，因此开发一个稳定且完整的安装接口成为一项挑战，该接口需能够使用不同的传输方式，同时不产生过度开销。在开发此接口时，必须仔细考虑解耦问题。

更新包存储
功能：由于预计车辆使用寿命内将发生大量软件更新事务，因此在安装开始前稳定且充足的更新包本地存储是必要的。此外，还需具备存储管理功能，以预留空间用于下一个更新包；需具备访问控制功能，以管理其他车辆功能对存储服务的使用；并需维护完整性，提供安全访问，这些均为必要的子服务。内存的读写周期相对于剩余预期寿命必须作为自诊断的一部分包含在内。
接口：需要提供抽象接口以访问实际的硬件存储，同时通过稳定的接口暴露存储服务。

以下是远程元素

这些软件实体不驻留在车辆中——它们可以是单个软件元素或复合软件实体的一部分。

企业控制服务器
功能：由于远程服务器知晓软件更新的需求，并将该信息传达给车辆，因此控制端到端系统的服务更集中于服务器而非车辆。此外，当系统出现故障或有恶意元件侵入时，禁用系统部分功能的能力也位于远程服务器。它还可以作为调度器，连接至其他各种企业级服务和云。
接口：需要具备启动软件更新过程以及从启动到完成期间获取状态的能力。还希望具备为一组车辆取消正在进行的流程的能力。

企业下载服务器
功能：主要出于商业原因，车辆ECU的汽车软件存储在OEM场所。尽管维修站服务基础设施要求所有软件都必须随时可用，但现有容量可能需要扩展以适应自动化。此外，由于其中一个传输环节是无线传输，因此无法容忍过长的服务器端延迟。
接口：在此领域，建议基于互联网标准交付文件，以考虑安全性和安全考虑。

Cloud Content Accessor Capability
功能：由于远程存储容量利用率取决于软件更新的使用情况，因此端到端设计应具有灵活性，以适应存储服务的云托管。信息娱乐领域中的一些商业软件组件更适合从云下载。
接口：采用云服务接口而非开发专有软件是明智之举。

安全服务器能力
功能：如前所述，安全涉及监控活动，必要时进行更新以防止恶意行为者访问。必须将远程服务的安全方面与内部活动分开，并保持为内部活动。
接口：监控关键活动的能力、在系统中添加/删除消息的能力、管理证书过期和吊销是关键要素。