CN111133412A - 基于工具链构建车辆ecu软件的软件增量更新和异常检测 - Google Patents

Abstract

公开的实施例涉及生成用于更新车辆中的电子控制单元(ECU)上的软件的更新包。操作可以包括：访问要存储在车辆中的ECU上的软件更新的多个属性；访问存储在车辆中的ECU上的当前软件的对应的多个属性；将所述多个属性与所述对应的多个属性进行比较；生成表示在所述比较中确定的所述多个属性和所述对应的多个属性之间的差异的增量文件；以及向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中执行。

Description

基于工具链构建车辆ECU软件的软件增量更新和异常检测

相关申请的交叉引用

本申请要求于2017年7月25日提交的第62/536,767号美国临时专利申请和于2017年9月19日提交的第62/560,224号美国临时专利申请的优先权，其全部内容通过引用并入本文。

背景技术

现代车辆利用许多电子控制单元(Electronic Control Unit，ECU)来控制诸如发动机、传动系统、变速器、制动器、悬架、车载娱乐系统、通信系统等组件的操作。ECU控制从动力转向到制动再到加速的现代车辆的基本操作。此外，ECU控制车辆中的许多附加功能和分析功能。例如，一些汽车可能配备有被配置为收集和分析驾驶数据的ECU，这些数据可以被提供给保险公司以确定保险费。一些汽车可能配备有被配置为增强驾驶体验的ECU，并且一些可能配备有被配置为提供高级(或自动)驾驶辅助的ECU。

随着ECU的复杂度和复杂性不断增加，管理ECU上的软件性能、升级和错误修复正在成为一项挑战。目前，一辆普通汽车中大约有60到70个ECU(并且一辆豪华汽车中大约有180个ECU)。这些ECU对应于数千万行代码。维护代码变得越来越困难。此外，高度复杂的软件倾向于更容易出现漏洞(vulnerabilities)，诸如软件错误、小故障和校准问题。ECU的制造商或开发商可能希望一旦发现就立即修复这些漏洞。

ECU中另一类型的漏洞与ECU错误或故障有关。ECU错误可以是例如运行时错误、堆栈上溢、堆栈下溢等。ECU故障可以是例如ECU的正常或预期操作中的偏差(例如，每时间间隔执行某功能一定次数，但随后突然或随时间缓慢地“漂移(drifting)”到执行该功能不同的次数)。在ECU软件的运行中缓慢实现的漂移可能是一个特别困难的问题，因为由于缺乏任何ECU操作改变的明显迹象，其很难被立即检测到。

解决受影响的车辆中的这些漏洞的一种方法是发出召回。然而，召回可能很耗时，并且不能对受影响的车辆将被及时修复提供任何保证。可选地，制造商或开发商可以尝试通过车载诊断(On-Board Diagnostic，OBD)端口或空中(例如，使用各种类型的无线通信技术)向受影响的车辆提供修复。然而，OBD端口本身就是车辆的攻击面(attack surface)，并且空中(over-the-air)修复通常效率低下，给车主带来不便，并且容易引入额外的错误。

此外，OBD和空中更新技术的当前尝试在时间和空间效率方面仍有限制。例如，空中更新技术的当前尝试要求制造商将整个ECU软件的新版本作为替换包分发给受影响的车辆。当受影响的车辆接收到替换包时，受影响的车辆要求将替换包存储到备用存储器空间(即，ECU未使用的存储器空间)，从由ECU使用的存储器空间中擦除当前版本的ECU软件，将替换包从备用存储器空间复制到由ECU使用的存储器空间中，并重新启动ECU，以便它可以加载新版本的ECU软件。由于显著的存储空间限制以及对ECU的运行的中断，这在ECU中几乎是不可能的。ECU几乎已经装满了现有的软件和数据，并且用于新软件或数据的可用存储空间非常有限。此外，向ECU提供新软件存在显著的成本限制。此外，取决于ECU的角色和车辆的状况，中断ECU的处理流可能不方便或非常危险。

因此，需要技术解决方案来生成、接收和处理更新包，以便在没有上述缺点的情况下更新ECU上的软件。具体地，需要解决方案来通过空中(over the air)且在ECU上没有专用客户端的情况下，用差量软件而不是整个软件模块或软件包来更新车辆。此外，解决方案不应要求显著的额外存储器使用，或ECU本身的任何停机(downtime)。此外，这样的解决方案不应需要对ECU的存储器进行重新编程。此外，这样的解决方案应该允许将ECU上的软件版本回滚(roll back)到先前版本，而不需要下载整个软件模块，不需要对存储器进行重新编程(这可能是昂贵的、耗时的和破坏性的)，并且同样不需要显著的存储器要求或ECU的任何停机。

还需要技术解决方案来生成用于异常检测的数据，其将不会消耗大量的数据吞吐量来存储或传输。利用其所需的所有资源，并且不需要额外所需的资源，这样的技术应该提供精益运行性能，以使ECU上的主要应用保持运行。进一步有利的是利用仅向控制中心或服务器发送动作调用(例如，基于通过机器学习的异常检测)以执行响应动作的分布式车辆架构解决方案。

此外，需要技术解决方案来应对基于车辆中的ECU之间的依赖性而产生的问题。例如，当一个ECU上的软件被更新时，它可能使得ECU不能与车辆中的其它ECU通信。例如，当对ECU的更新影响其网络地址、输入或输出通信策略、数据通信的格式或有效载荷、通信的定时、通信协议或其功能的各种其它属性时，这可能发生。因此，能够管理ECU之间的依赖性，使得对ECU的软件更新能够在可能受到更新的影响的所有ECU上进行协调和执行将是有利的。

发明内容

所公开的实施例描述了用于生成用于更新车辆中的电子控制单元(ECU)上的软件的更新包的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以存在包括指令的非暂时性计算机可读介质，当由至少一个处理器运行时，所述指令使得所述至少一个处理器执行用于生成用于更新车辆中的ECU上的软件的更新包的操作。所述操作可以包括：访问要存储在车辆中的ECU上的软件更新的多个属性；访问存储在车辆中的ECU上的当前软件的对应的多个属性；将所述多个属性与对应的多个属性进行比较；生成表示在所述比较中确定的所述多个属性和对应的多个属性之间的差异的增量文件(delta file)；以及向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中运行。

根据所公开的实施例，启动代码被集成到增量文件中。

根据所公开的实施例，启动代码在增量文件被ECU接收之前被安装在ECU上。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库。

根据所公开的实施例，启动代码被配置为更新ECU的程序计数器以运行包含在增量文件中的指令。

根据所公开的实施例，增量文件包括表示软件更新所引用的变量的值的变量数据。

根据所公开的实施例，启动代码被配置为从增量文件中提取变量数据，并将变量数据放置到ECU可访问的存储器中。

根据所公开的实施例，增量文件包括用于更新ECU中的存储器地址的代码。

根据所公开的实施例，启动代码被配置为提取用于更新存储器地址的代码并更新ECU中的存储器地址。

根据所公开的实施例，ECU上的软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(Virtual File System，VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，要存储在ECU上的软件更新的多个属性包括由VFS管理的多个功能单元中的至少一个。

根据所公开的实施例，指令还包括：将第一网格应用于软件更新；将第二网格应用于存储在ECU上的当前软件；以及基于第一网格和第二网格的比较来标识多个属性和对应的多个属性。

根据所公开的实施例，第一网格在一个或多个维度上表示软件更新，一个或多个维度包括以下中的至少一个：与软件更新相关联的二进制数据、与软件更新相关联的源属性、以及与软件更新相关联的映射文件。

根据所公开的实施例，至少部分地基于用于开发软件更新的编程语言来标识多个属性。

根据所公开的实施例，至少部分地基于软件更新的二进制文件分辨率来标识多个属性。

根据所公开的实施例，至少部分地基于与软件更新相关联的映射文件来标识多个属性。

根据所公开的实施例，软件更新是单片文件(monolithic file)。

根据所公开的实施例，软件更新是与其它文件相互依赖的文件。

根据所公开的实施例，操作包括，在将增量文件提供给ECU之前，检查依赖性系统以确定是否应该基于正被提供给ECU的增量文件来更新任何相互依赖的ECU。

根据所公开的实施例，操作还包括自动向相互依赖的ECU提供额外的增量文件以在相互依赖的ECU上执行软件更新。

根据所公开的实施例，可以实现一种用于更新车辆中的ECU上的软件的系统。所述系统可以包括：一个或多个处理器；以及一个或多个存储器，其具有指令，当由所述一个或多个处理器运行时，所述指令使得所述一个或多个处理器执行以下操作：访问要存储在车辆中的ECU上的软件更新的多个属性；访问存储在车辆中的ECU上的当前软件的对应的多个属性；将所述多个属性与对应的多个属性进行比较；生成表示在所述比较中确定的所述多个属性和对应的多个属性之间的差异的增量文件；以及向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中运行。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库(runtimelibrary)。

根据所公开的实施例，可以实现一种用于更新车辆中的ECU上的软件的方法。所述方法可以包括：访问要存储在车辆中的ECU上的软件更新的多个属性；访问存储在车辆中的ECU上的当前软件的对应的多个属性；将所述多个属性与对应的多个属性进行比较；生成表示在所述比较中确定的所述多个属性和对应的多个属性之间的差异的增量文件；以及向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中运行。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库。

所公开的实施例描述了用于在车辆中接收和集成增量文件的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以存在包括指令的非暂时性计算机可读介质，当由至少一个处理器运行时，所述指令使得所述至少一个处理器执行用于在车辆中接收和集成增量文件的操作。所述操作可以包括：在车辆中的电子控制单元(ECU)处接收增量文件，所述增量文件包括与用于ECU上的软件的软件更新相对应的多个增量和用于在ECU中运行增量文件的启动代码；基于所述启动代码，在ECU中运行所述增量文件；以及更新ECU中的存储器地址，以对应于来自所述增量文件的多个增量。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库。

根据所公开的实施例，增量文件包括要由ECU运行的与位置无关的可运行代码段。

根据所公开的实施例，启动代码被配置为更新ECU的程序计数器以运行包含在增量文件中的指令。

根据所公开的实施例，启动代码被配置为从增量文件提取数据以存储在ECU上。

根据所公开的实施例，启动代码被配置为将增量文件链接到与增量文件相关联的虚拟文件系统中的特定功能。

根据所公开的实施例，增量文件包括用于更新ECU中的存储器地址的代码。

根据所公开的实施例，启动代码被配置为提取用于更新存储器地址的代码并更新ECU中的存储器地址。

根据所公开的实施例，增量文件被写入与ECU相关联的闪存。

根据所公开的实施例，增量文件被从闪存引导至与ECU相关联的随机存取存储器。

根据所公开的实施例，增量文件可在不影响ECU的继续操作的情况下由ECU运行。

根据所公开的实施例，增量文件可在不重启ECU的情况下运行。

根据所公开的实施例，可以实现一种用于接收增量文件并将其集成到车辆中的ECU中的系统。所述系统可以包括：一个或多个处理器；以及一个或多个存储器，其具有指令，当由一个或多个处理器运行时，所述指令使得所述一个或多个处理器执行以下操作：在车辆中的ECU处接收增量文件，所述增量文件包括与用于ECU上的软件的软件更新相对应的多个增量和用于在ECU中执行增量文件的启动代码；基于所述启动代码，在ECU中运行所述增量文件；以及更新ECU中的存储器地址以对应于来自所述增量文件的多个增量。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库。

根据所公开的实施例，增量文件包括要由车辆的ECU运行的与位置无关的可运行代码段。

根据所公开的实施例，增量文件包括用于确定是否删除ECU中存储器的内容的代码。

根据所公开的实施例，启动代码被配置为指示ECU删除ECU中存储器的特定内容。

根据所公开的实施例，ECU上的软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，增量文件可在不影响ECU的继续操作的情况下运行。

根据所公开的实施例，实现一种用于接收增量文件并将其集成到车辆中的ECU中的方法。所述方法可以包括：在车辆中的ECU处接收增量文件，所述增量文件包括与用于ECU上的软件的软件更新相对应的多个增量和用于在ECU中运行增量文件的启动代码；基于所述启动代码，在ECU中运行所述增量文件；以及更新ECU中的存储器地址，以对应于来自所述增量文件的多个增量。

所公开的实施例描述了用于在车辆的ECU正在运行时对电子控制单元(ECU)软件执行更新的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以存在包括指令的非暂时性计算机可读介质，当由至少一个处理器运行时，所述指令使得所述至少一个处理器执行用于在车辆的ECU正在运行时对ECU软件执行更新的操作。所述操作可以包括：在车辆的ECU正在运行时，在车辆处接收用于ECU软件的软件更新文件；在ECU正在运行时，将所述软件更新文件写入ECU的存储器中的第一存储器位置，同时运行ECU的存储器中的第二存储器位置中的现有代码的代码段；以及基于所述软件更新文件来更新与ECU的存储器相关联的多个存储器地址，并且不中断当前正在运行的ECU的存储器中的第二存储器位置中的代码段的运行。

根据所公开的实施例，ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，更新与ECU的存储器相关联的多个存储器地址包括更新通过VFS管理的多个功能单元的多个存储器地址。

根据所公开的实施例，软件更新文件是增量文件。

根据所公开的实施例，增量文件包括被集成到增量文件中并且被配置用于在ECU中运行增量文件的启动代码。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库。

根据所公开的实施例，指令还可以包括：在将软件更新文件写入ECU的第一存储器位置之前初始化运行时库。

根据所公开的实施例，启动代码被配置为更新ECU的程序计数器以运行包含在增量文件中的指令。

根据所公开的实施例，增量文件包括表示由软件更新所引用的变量的值的变量数据。

根据所公开的实施例，启动代码被配置为从增量文件中提取变量数据，并将变量数据放置到ECU可访问的随机存取存储器中。

根据所公开的实施例，指令还可以包括：删除表示由软件更新所引用的变量的先前值的数据。

根据所公开的实施例，增量文件包括用于更新ECU的存储器中的存储器地址的代码。

根据所公开的实施例，启动代码被配置为提取用于更新存储器地址的代码并更新ECU的存储器中的存储器地址。

根据所公开的实施例，指令还可以包括：在完成软件更新之后，对ECU的存储器进行碎片整理(defragment)。

根据所公开的实施例，可以实现一种在车辆的ECU正在运行时对ECU软件执行更新的系统。所述系统可以包括：一个或多个处理器；以及一个或多个存储器，其具有指令，当由所述一个或多个处理器运行时，所述指令使得所述一个或多个处理器执行以下操作：在车辆的ECU正在运行时，在车辆处接收用于ECU软件的软件更新文件；在ECU正在运行时，将所述软件更新文件写入ECU的存储器中的第一存储器位置，同时运行ECU的存储器中的第二存储器位置中的现有代码的代码段；以及基于所述软件更新文件来更新与ECU的存储器相关联的多个存储器地址，并且不中断ECU的存储器中的第二存储器位置中当前正运行的代码段的运行。

根据所公开的实施例，ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，更新与ECU的存储器相关联的多个存储器地址包括更新通过VFS管理的多个功能单元的多个存储器地址。

根据所公开的实施例，可以实现一种用于在车辆的ECU正在运行时对ECU软件执行更新的方法。所述方法可以包括：在车辆的ECU正在运行时，在车辆处接收用于ECU软件的软件更新文件；在ECU正在运行时，将所述软件更新文件写入ECU的存储器中的第一存储器位置，同时运行ECU的存储器中的第二存储器位置中的现有代码的代码段；以及基于所述软件更新文件来更新与ECU的存储器相关联的多个存储器地址，并且不中断ECU的存储器中的第二存储器位置中当前正在运行的代码段的运行。

根据所公开的实施例，ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，更新与ECU的存储器相关联的多个存储器地址包括更新通过VFS管理的多个功能单元的多个存储器地址。

所公开的实施例描述了用于调整车辆电子控制单元(ECU)软件版本的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以存在包括指令的非暂时性计算机可读介质，当由至少一个处理器运行时，所述指令使得所述至少一个处理器执行用于调整车辆电子控制单元(ECU)软件版本的操作。所述操作可以包括：接收将车辆的ECU从运行第一版本的ECU软件调整到运行第二版本的ECU软件的提示(prompt)；响应于所述提示并基于对应于第二版本的ECU软件的增量文件，在车辆中的ECU上配置第二版本的ECU软件用于运行；以及响应于所述提示，在车辆中的ECU上将第一版本的ECU软件配置成为不可运行。

根据所公开的实施例，第二版本的ECU软件在第一版本的ECU软件之后被部署(deploy)。

根据所公开的实施例，第二版本的ECU软件在第一版本的ECU软件之前被部署。

根据所公开的实施例，ECU上的ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，将第一版本的ECU软件配置成为不可运行还包括：更新ECU中对应于由VFS管理的一个或多个功能单元的存储器地址。

根据所公开的实施例，第二版本的ECU软件是具有被VFS禁用的一个或多个功能单元的第一版本的ECU软件。

根据所公开的实施例，对应于第二版本的ECU软件的增量文件被存储在ECU上。

根据所公开的实施例，增量文件包括被集成到增量文件中并且被配置用于在ECU中运行增量文件的启动代码。

根据所公开的实施例，启动代码被配置为初始化增量文件的运行时库。

根据所公开的实施例，指令还包括：在接收到将ECU从运行第一版本的ECU软件调整到运行第二版本的ECU软件的提示时，运行被包括在对应于第二版本的ECU软件的增量文件中的启动代码。

根据所公开的实施例，指令还包括：确定ECU的存储器的利用率高于阈值；以及标识用于删除的ECU的存储器的特定内容。

根据所公开的实施例，指令还包括：在完成删除之后，对ECU的存储器进行碎片整理。

根据所公开的实施例，可以实现一种调整车辆ECU软件版本的系统。所述系统可以包括：一个或多个处理器；和一个或多个存储器，其具有指令，当由所述一个或多个处理器执行时，所述指令使得所述一个或多个处理器执行以下操作：接收将车辆的ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示；响应于所述提示并基于对应于第二版本的ECU软件的增量文件，在车辆中的ECU上配置第二版本的ECU软件用于执行；以及响应于所述提示，在车辆中的ECU上将第一版本的ECU软件配置成为不可执行。

根据所公开的实施例，第二版本的ECU软件在第一版本的ECU软件之后被部署。

根据所公开的实施例，第二版本的ECU软件在第一版本的ECU软件之前被部署。

根据所公开的实施例，ECU上的ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，将第一版本的ECU软件配置成为不可执行可以包括：更新ECU中对应于由VFS管理的一个或多个功能单元的存储器地址。

根据所公开的实施例，第二版本的ECU软件是具有被VFS禁用的一个或多个功能单元的第一版本的ECU软件。

根据所公开的实施例，对应于第二版本的ECU软件的增量文件存储在ECU上。

根据所公开的实施例，可以实现一种用于调整车辆ECU软件版本的方法。所述方法可以包括：接收将车辆的ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示；响应于所述提示并基于对应于第二版本的ECU软件的增量文件，在车辆中的ECU上配置第二版本的ECU软件用于执行；以及响应于所述提示，在车辆中的ECU上将第一版本的ECU软件配置成为不可执行。

所公开的实施例描述了用于标识车辆中的电子控制单元(Electronic ControlUnit，ECU)异常的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以有包括指令的非暂时性计算机可读介质，当由至少一个处理器执行时，所述指令使得所述至少一个处理器执行用于标识车辆中的ECU异常的操作。所述操作可以包括：在车辆中监测表示ECU的实时处理活动的数据；在车辆中访问与ECU的处理活动相关的历史数据，所述历史数据表示ECU的预期处理活动；在车辆中将实时处理活动数据与历史数据进行比较，以标识ECU的实时处理活动中的至少一个异常；以及当标识出至少一个异常时，实施用于所述ECU的控制动作。

根据所公开的实施例，控制动作包括发出将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示。

根据所公开的实施例，ECU上的软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件包括：基于对应于第二版本的ECU软件的增量文件，更新由VFS管理的一个或多个功能单元的存储器地址。

根据所公开的实施例，指令还包括：监测ECU的操作以生成历史数据。

根据所公开的实施例，所述监测、访问、比较和实施发生在车辆中的协调器内，所述协调器与ECU分离。

根据所公开的实施例，协调器被配置为对车辆中的多个ECU运行所述监测、访问、比较和实施。

根据所公开的实施例，至少一个异常对应于由ECU使用的特定存储器位置。

根据所公开的实施例，至少一个异常对应于由ECU使用的存储器位置的特定序列。

根据所公开的实施例，至少一个异常对应于流入或流出ECU的数据中的至少一个峰值。

根据所公开的实施例，至少一个异常对应于由ECU的处理器正在处理的数据中的至少一个峰值。

根据所公开的实施例，至少一个异常对应于ECU的功耗中的至少一个异常。

根据所公开的实施例，控制动作包括发送与ECU相关联的警报。

根据所公开的实施例，控制动作包括阻止从ECU发送的指令。

根据所公开的实施例，控制动作包括将运行在ECU上的ECU软件的版本回滚到ECU软件的先前版本。

根据所公开的实施例，可以实现一种用于标识车辆中的ECU异常的系统。所述系统可以包括：一个或多个处理器；和一个或多个存储器，其具有指令，当由所述一个或多个处理器执行时，所述指令使得所述一个或多个处理器执行以下操作：在车辆中监测表示ECU的实时处理活动的数据；在车辆中访问与ECU的处理活动相关的历史数据，所述历史数据表示ECU的预期处理活动；在车辆中将实时处理活动数据与历史数据进行比较，以标识ECU的实时处理活动中的至少一个异常；以及当标识出至少一个异常时，实施用于所述ECU的控制动作。

根据所公开的实施例，控制动作包括发出将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示。

根据所公开的实施例，所述监测、访问、比较和实施发生在车辆中的协调器内，所述协调器与ECU分离。

根据所公开的实施例，协调器被配置为对车辆中的多个ECU运行所述监测、访问、比较和实施。

根据所公开的实施例，可以实现一种用于标识车辆中的ECU异常的方法。所述方法可以包括：在车辆中监测表示ECU的实时处理活动的数据；在车辆中访问与ECU的处理活动相关的历史数据，所述历史数据表示ECU的预期处理活动；在车辆中将实时处理活动数据与历史数据进行比较，以标识ECU的实时处理活动中的至少一个异常；以及当标识出至少一个异常时，实施用于所述ECU的控制动作。

所公开的实施例描述了用于标识车辆中的电子控制单元(ECU)异常的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以有包括指令的非暂时性计算机可读介质，当由至少一个处理器执行时，所述指令使得所述至少一个处理器执行用于标识车辆中的ECU异常的操作。所述操作可以包括：监测表示ECU的实时处理活动的数据；接收与被认为在功能上与所述ECU可比的至少一个其它ECU的处理活动相关的可比数据；将实时处理活动数据与可比数据进行比较，以标识ECU的实时处理活动中的至少一个异常；以及当标识出至少一个异常时，实施用于所述ECU的控制动作。

根据所公开的实施例，控制动作包括发出将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示。

根据所公开的实施例，ECU上的软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件包括：基于对应于第二版本的ECU软件的增量文件，更新由VFS管理的一个或多个功能单元的存储器地址。

根据所公开的实施例，可比数据包括实时获得的与被认为与所述ECU可比的多个其它ECU的处理活动相关的数据。

根据所公开的实施例，可比数据包括先前收集的与被认为与所述ECU可比的多个其它ECU的处理活动相关的数据。

根据所公开的实施例，接收可比数据还包括：基于与运行在ECU上的ECU软件相关联的规则来获得可比数据。

根据所公开的实施例，接收可比数据还包括：基于运行在ECU上的ECU软件的已知有效执行序列来获得可比数据。

根据所公开的实施例，接收可比数据还包括：基于运行在ECU上的ECU软件的已知潜在恶意执行序列来获得可比数据。

根据所公开的实施例，接收可比数据还包括：基于与ECU上的ECU软件相关联的映射文件来获得可比数据。

根据所公开的实施例，接收可比数据还包括：从其它车辆接收观测数据；以及基于观测数据来获得可比数据。

根据所公开的实施例，至少一个异常对应于由ECU使用的特定存储器位置。

根据所公开的实施例，至少一个异常对应于由ECU使用的存储器位置的特定序列。

根据所公开的实施例，至少一个异常对应于流入或流出ECU的数据中的至少一个峰值。

根据所公开的实施例，至少一个异常对应于由ECU的处理器正在处理的数据中的至少一个峰值。

根据所公开的实施例，至少一个异常对应于ECU的功耗中的至少一个异常。

根据所公开的实施例，控制动作包括以下至少一个：发送与ECU相关联的警报，阻止从ECU发送的指令，或者将运行在ECU上的软件的版本回滚到软件的先前版本。

根据所公开的实施例，可以实现一种用于标识车辆中的ECU异常的系统。所述系统可以包括：一个或多个处理器；和一个或多个存储器，其具有指令，当由所述一个或多个处理器执行时，所述指令使得所述一个或多个处理器执行以下操作：监测表示ECU的实时处理活动的数据；接收与被认为在功能上与所述ECU可比的至少一个其它ECU的处理活动相关的可比数据；将实时处理活动数据与可比数据进行比较，以标识ECU的实时处理活动中的至少一个异常；以及当标识出至少一个异常时，实施用于所述ECU的控制动作。

根据所公开的实施例，控制动作包括发出将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示。

根据所公开的实施例，可以实现一种用于标识车辆中的ECU异常的方法。所述方法可以包括：监测表示ECU的实时处理活动的数据；接收与被认为在功能上与所述ECU可比的至少一个其它ECU的处理活动相关的可比数据；将实时处理活动数据与可比数据进行比较，以标识ECU的实时处理活动中的至少一个异常；以及当标识出至少一个异常时，实施用于所述ECU的控制动作。

所公开的实施例描述了用于适时地更新车辆中的电子控制单元(ECU)软件的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以有包括指令的非暂时性计算机可读介质，当由至少一个处理器执行时，所述指令使得所述至少一个处理器执行用于适时地更新车辆中的电子控制单元(ECU)软件的操作。所述操作可以包括：在车辆中的控制器处接收指示需要更新运行在车辆中的至少一个ECU上的软件的无线传输；监测车辆的运行状态，以确定车辆是否处于禁止ECU软件更新的第一运行模式(a first mode ofoperation)；当运行状态被禁止时，延迟ECU软件更新；继续监测车辆的运行状态，以确定车辆是否处于允许ECU软件更新的第二运行模式；以及当确定车辆处于第二运行模式时，使能(enable)用延迟的ECU软件来更新所述至少一个ECU。

根据所公开的实施例，继续监测车辆的运行状态包括根据预先建立的间隔重复监测车辆的运行状态。

根据所公开的实施例，指令还包括：当车辆处于第一运行模式时，将ECU软件更新存储在位于车辆上的存储器中用于延迟更新。

根据所公开的实施例，当车辆处于第一运行模式时，延迟的软件更新被维护在远离车辆的服务器上，并且指令还可以包括：当车辆处于第二运行模式时，向远程服务器发送消息；接收回复所述消息的ECU软件更新；以及当车辆处于第二运行模式时，在车辆中的至少一个ECU上安装ECU软件更新。

根据所公开的实施例，第二运行模式包括多个预定安全运行条件中的一个。

根据所公开的实施例，第二运行模式包括车辆的断电状态。

根据所公开的实施例，第二运行模式包括车辆的怠速状态(idling status)。

根据所公开的实施例，第二运行模式包括无线通信强度高于强度阈值的时段。

根据所公开的实施例，第二运行模式包括车辆的预选的环境条件。

根据所公开的实施例，第二运行模式包括误码率低于阈值的网络连接。

根据所公开的实施例，指示需要更新软件的无线传输包括更新是否具有超驰状态(verride status)的指示。

根据所公开的实施例，指令还包括：当接收到具有超驰状态的更新时，更新ECU软件，而不管车辆是否处于第一运行模式。

根据所公开的实施例，ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，可以实现一种用于适时地更新车辆中的ECU软件的系统。所述系统可以包括：一个或多个处理器；和一个或多个存储器，其具有指令，当由所述一个或多个处理器执行时，所述指令使得所述一个或多个处理器执行以下操作：在车辆中的控制器处接收指示需要更新运行在车辆中的至少一个ECU上的软件的无线传输；监测车辆的运行状态，以确定车辆是否处于禁止ECU软件更新的第一运行模式；当运行状态被禁止时，延迟ECU软件更新；继续监测车辆的运行状态，以确定车辆是否处于允许ECU软件更新的第二运行模式；以及当确定车辆处于第二运行模式时，使能用延迟的ECU软件来更新所述至少一个ECU。

根据所公开的实施例，继续监测车辆的运行状态包括根据预先建立的间隔重复监测车辆的运行状态。

根据所公开的实施例，指示需要更新软件的无线传输包括更新是否具有超驰状态的指示。

根据所公开的实施例，一个或多个处理器还被配置为执行以下操作：当接收到具有超驰状态的更新时，更新ECU软件，而不管车辆是否处于第一运行模式。

根据所公开的实施例，可以实现一种用于适时地更新车辆中的ECU软件的方法。所述方法可以包括：在车辆中的控制器处接收指示需要更新运行在车辆中的至少一个ECU上的软件的无线传输；监测车辆的运行状态，以确定车辆是否处于禁止ECU软件更新的第一运行模式；当运行状态被禁止时，延迟ECU软件更新；继续监测车辆的运行状态，以确定车辆是否处于允许ECU软件更新的第二运行模式；以及当确定车辆处于第二运行模式时，使能用延迟的ECU软件来更新所述至少一个ECU。

根据所公开的实施例，继续监测车辆的运行状态包括根据预先建立的间隔重复监测车辆的运行状态。

根据所公开的实施例，指示需要更新软件的无线传输包括更新是否具有超驰状态的指示，并且所述方法还可以包括：当接收到具有超驰状态的更新时，更新ECU软件，而不管车辆是否处于第一运行模式。

所公开的实施例描述了用于自动向至少一个车辆提供更新的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以有包括指令的非暂时性计算机可读介质，当由至少一个处理器执行时，所述指令使得所述至少一个处理器执行用于自动向所述至少一个车辆提供更新的操作。所述操作可以包括：在远离所述至少一个车辆的服务器处接收来自所述至少一个车辆的电子控制单元(ECU)活动数据，所述ECU活动数据对应于所述至少一个车辆中ECU的实际操作；在所述服务器处基于所述ECU活动数据来确定影响所述至少一个车辆的软件漏洞(software vulnerability)，所述软件漏洞是基于接收的ECU活动数据和预期的ECU活动数据之间的偏差来确定的；在所述服务器处基于所确定的软件漏洞来标识ECU软件更新；以及从所述服务器发送增量文件，所述增量文件被配置为用对应于所标识的ECU软件更新的软件更新来更新ECU上的软件。

根据所公开的实施例，至少一个车辆包括作为组被监测的多个车辆。

根据所公开的实施例，多个车辆包括具有共同ECU类型的第一车辆集合。

根据所公开的实施例，确定软件漏洞包括：确定影响第一车辆集合的软件漏洞。

根据所公开的实施例，确定软件漏洞还包括：基于ECU活动数据，确定可能受软件漏洞影响的多个车辆的第二集合。

根据所公开的实施例，发送被配置为用软件更新来更新ECU上的软件的增量文件包括：向第一车辆集合和第二车辆集合发送多个增量文件。

根据所公开的实施例，ECU软件更新包括将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件的提示。

根据所公开的实施例，指令还包括：响应于提示并基于对应于第二版本的ECU软件的增量文件，在ECU上配置第二版本的ECU软件用于执行；以及响应于提示，在ECU上将第一版本的ECU软件配置成为不可执行。

根据所公开的实施例，第二版本的ECU软件在第一版本的ECU软件之后被部署。

根据所公开的实施例，第二版本的ECU软件在第一版本的ECU软件之前被部署。

根据所公开的实施例，ECU上的软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，第二版本的ECU软件是具有被VFS禁用的一个或多个功能单元的第一版本的ECU软件。

根据所公开的实施例，增量文件包括被集成到增量文件中并且被配置用于在ECU中执行增量文件的启动代码。

根据所公开的实施例，ECU软件更新包括用于在ECU上安装ECU软件更新的安装代理。

根据所公开的实施例，ECU软件更新被配置为重新校准多个车辆中的ECU。

根据所公开的实施例，指令还包括：响应于ECU软件更新，指示至少一个车辆的ECU重启。

根据所公开的实施例，可以实现一种用于自动向至少一个车辆提供更新的系统。所述系统可以包括：一个或多个处理器；和一个或多个具有指令的存储器，当由所述一个或多个处理器执行时，所述指令使得所述一个或多个处理器执行以下操作：在远离所述至少一个车辆的服务器处接收来自所述至少一个车辆的电子控制单元(ECU)活动数据，所述ECU活动数据对应于所述至少一个车辆中ECU的实际操作；在所述服务器处基于所述ECU活动数据来确定影响所述至少一个车辆的软件漏洞，所述软件漏洞是基于接收的ECU活动数据和预期的ECU活动数据之间的偏差来确定的；在所述服务器处基于所确定的软件漏洞来标识ECU软件更新；以及从所述服务器发送增量文件，所述增量文件被配置为用对应于所标识的ECU软件更新的软件更新来更新ECU上的软件。

根据所公开的实施例，至少一个车辆包括具有共同ECU类型的第一车辆集合，并且一个或多个处理器还被配置为执行以下操作：确定影响第一车辆集合的软件漏洞；以及基于ECU活动数据，确定可能受软件漏洞影响的第二车辆集合。

根据所公开的实施例，一个或多个处理器还被配置为执行以下操作：向第一车辆集合和第二车辆集合发送ECU软件更新。

根据所公开的实施例，可以实现一种用于自动向至少一个车辆提供更新的方法。所述方法可以包括：在远离所述至少一个车辆的服务器处接收来自所述至少一个车辆的电子控制单元(ECU)活动数据，所述ECU活动数据对应于所述至少一个车辆中ECU的实际操作；在所述服务器处基于所述ECU活动数据来确定影响所述至少一个车辆的软件漏洞，所述软件漏洞是基于接收的ECU活动数据和预期的ECU活动数据之间的偏差来确定的；在所述服务器处基于所述软件漏洞来标识ECU软件更新；以及从所述服务器发送增量文件，所述增量文件被配置为用对应于所标识的ECU软件更新的软件更新来更新ECU上的软件。

所公开的实施例描述了用于向远程监测服务器报告电子控制单元(ECU)错误或故障的非暂时性计算机可读介质和方法。例如，在示例性实施例中，可以有包括指令的非暂时性计算机可读介质，当由至少一个处理器执行时，所述指令使得所述至少一个处理器执行用于向远程监测服务器报告ECU错误或故障的操作。所述操作可以包括：在车辆的通信网络中的处理器处，从车辆中的多个ECU接收运行数据，所述运行数据指示多个ECU的多个运行时属性(runtime attribute)；通过机器学习过程生成运行数据的统计模型，其中，机器学习过程基于多个运行时属性；从车辆的通信网络中的多个ECU接收实时(live)运行时更新(runtime update)；基于实时运行时更新，标识与车辆的通信网络中的ECU相关联的ECU错误，所述ECU错误是通过将实时运行时更新与运行数据的统计模型进行比较以标识与运行数据的至少一个偏差来确定的；以及基于实时运行时更新，从车辆向远程监测服务器无线地发送报告，所述报告标识ECU和标识出的ECU错误。

根据所公开的实施例，操作包括向ECU发送请求消息，响应于该请求消息，ECU能够做出一个或多个正确的响应消息来指示正确的ECU操作。

根据所公开的实施例，基于ECU未能响应请求消息来标识ECU错误。

根据所公开的实施例，基于ECU不正确地响应请求消息来标识ECU错误。

根据所公开的实施例，基于在ECU中检测到的堆栈上溢来标识ECU错误。

根据所公开的实施例，远程监测服务器根据多层模型来操作，其中，多层中的一层包括从车辆接收实时运行时更新的样本，用于在远程监测服务器处进一步分析。

根据所公开的实施例，远程监测服务器根据多层模型来操作，其中，多层中的一层包括从车辆接收在ECU中使用的增量文件的标识。

根据所公开的实施例，远程监测服务器根据多层模型来操作，其中，多层中的一层包括确定将ECU的软件版本回滚到先前的软件版本。

根据所公开的实施例，远程监测服务器根据多层模型来操作，其中，多层中的一层包括确定为ECU实施安全模式。

根据所公开的实施例，操作还包括确定标识出的ECU错误是否对ECU有害。

根据所公开的实施例，机器学习过程基于ECU的存储器使用模式。

根据所公开的实施例，机器学习过程基于ECU上的软件执行模式。

根据所公开的实施例，ECU上的ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(VFS)来管理和跟踪多个功能单元中的每一个的一个或多个版本。

根据所公开的实施例，操作还包括在ECU上配置第二版本的ECU软件用于执行，包括更新通过VFS管理的多个功能单元中的一个或多个的存储器地址。

根据所公开的实施例，第二版本的ECU软件是具有被VFS禁用的一个或多个功能单元的先前版本的ECU软件。

根据所公开的实施例，运行数据包括多个ECU的标识符。

根据所公开的实施例，运行数据包括指示多个ECU的最后已知轮询(last-knownpoll)的数据。

根据所公开的实施例，指令还包括：基于运行数据和实时运行时更新来确定多个ECU的停机概率。

根据所公开的实施例，可以实现一种用于向远程监测服务器报告ECU错误或故障的系统。所述系统可以包括：一个或多个处理器；和一个或多个存储器，其具有指令，当由所述一个或多个处理器执行时，所述指令使得所述一个或多个处理器执行以下操作：在车辆的通信网络中的处理器处，从车辆中的多个ECU接收运行数据，所述运行数据指示多个ECU的多个运行时属性；通过机器学习过程生成运行数据的统计模型，其中，机器学习过程基于多个运行时属性；从车辆的通信网络中的多个ECU接收实时运行时更新；基于实时运行时更新，标识与车辆的通信网络中的ECU相关联的ECU错误，所述ECU错误是通过将实时运行时更新与运行数据的统计模型进行比较以标识与运行数据的至少一个偏差来确定的；以及基于实时运行时更新，从车辆向远程监测服务器无线地发送报告，所述报告标识ECU和标识出的ECU错误。

根据所公开的实施例，可以实现一种用于向远程监测服务器报告ECU错误或故障的方法。所述方法可以包括：在车辆的通信网络中的处理器处，从车辆中的多个ECU接收运行数据，所述运行数据指示多个ECU的多个运行时属性；通过机器学习过程生成运行数据的统计模型，其中，机器学习过程基于多个运行时属性；从车辆的通信网络中的多个ECU接收实时运行时更新；基于实时运行时更新，标识与车辆的通信网络中的ECU相关联的ECU错误，所述ECU错误是通过将实时运行时更新与运行数据的统计模型进行比较以标识与运行数据的至少一个偏差来确定的；以及基于实时运行时更新，从车辆向远程监测服务器无线地发送报告，所述报告标识ECU和标识出的ECU错误。

所公开的实施例的各方面可以包括存储软件指令的有形计算机可读介质，当由一个或多个处理器执行时，所述软件指令被配置用于并且能够执行和运行与所公开的实施例一致的方法、操作等中的一个或多个。此外，所公开的实施例的各方面可以由一个或多个处理器来执行，所述一个或多个处理器被配置为基于用逻辑和指令编程的软件指令的(多个)专用处理器，所述逻辑和指令在被执行时执行与所公开的实施例一致的一个或多个操作。

应当理解，前面的一般描述和下面的详细描述都只是示例性和解释性的，而不是对如所要求保护的所公开的实施例的限制。

附图说明

结合在本说明书中并构成其一部分的附图示出了所公开的实施例，并且与说明书一起用于解释所公开的实施例。在附图中：

图1A是根据所公开的实施例的示例系统的框图。

图1B是根据所公开的实施例的其中可以创建和部署增量文件并且可以监测ECU的操作的系统环境的图示。

图1C是根据所公开的实施例的车辆通信网络的图示。

图2是描绘根据所公开的实施例的示例性ECU软件更新过程的图示。

图3是描绘根据所公开的实施例的生成增量文件的示例过程的图示。

图4是描绘根据所公开的实施例的被配置为更新ECU的程序计数器的启动代码的图示。

图5是描绘根据所公开的实施例的包括对不同代码段的代码改变的增量文件的图示。

图6是描绘根据所公开的实施例的可用于ECU进行更新的增量文件的图示。

图7是描绘根据所公开的实施例的可用于ECU进行更新的增量文件的另一图示。

图8是描绘根据所公开的实施例的可用于ECU进行更新的增量文件的又一图示。

图9是描绘根据所公开的实施例的可用于ECU的软件更新的时间线视图的图示。

图10是示出根据所公开的实施例的用于生成用于更新车辆中的ECU上的软件的更新包的过程的示例性流程图。

图11是示出根据所公开的实施例的用于在车辆中接收和集成增量文件的过程的示例性流程图。

图12是示出根据所公开的实施例的在车辆的ECU正在运行时对ECU软件执行更新的过程的示例性流程图。

图13是示出根据所公开的实施例的用于调整车辆ECU软件版本的过程的示例性流程图。

图14是示出根据所公开的实施例的用于标识车辆中的ECU异常的过程的示例性流程图。

图15是示出根据所公开的实施例的用于标识车辆中的ECU异常的过程的示例性流程图。

图16是示出根据所公开的实施例的用于适时地更新车辆中的ECU软件的过程的示例性流程图。

图17是示出根据所公开的实施例的用于自动向一个或多个车辆提供更新的过程的示例性流程图。

图18是示出根据所公开的实施例的用于向远程监测服务器报告ECU错误的过程的示例性流程图。

具体实施方式

在以下详细描述中，阐述了许多具体细节，以便提供对所公开的示例实施例的透彻理解。然而，本领域技术人员将理解，示例实施例的原理可以在没有每个具体细节的情况下实践。没有详细描述众所周知的方法、过程和组件，以免模糊示例实施例的原理。除非明确声明，否则本文描述的示例方法和过程不被约束于特定的顺序或序列，或者不被约束于特定的系统配置。此外，一些所描述的实施例或其元素可以同时地、在同一时间点、或并发地发生或执行。

现在将详细参考所公开的实施例，其示例在附图中示出。

图1A是根据所公开的实施例的示例系统100的框图。如图所示，系统100包括被配置为通过通信信道106与一个或多个车辆104通信的一个或多个服务器(或计算机)102。通信信道106可以包括总线、电缆、无线通信信道、基于无线电的通信信道、互联网、局域网(Local Area Network，LAN)、无线局域网(Wireless Local Area Network，WLAN)、广域网(Wide Area Network，WAN)、蜂窝通信网络或任何基于互联网协议(Internet Protocol，IP)的通信网络等。在一些实施例中，通信信道106可以基于公共云基础设施、私有云基础设施、混合公共/私有云基础设施或无云基础设施。在这些不同的实施例中，服务器102和车辆104可以各自位于相同或不同的网络或网段中。在一些实施例中，车辆104可以配备有被配置为支持经由通信信道106与服务器102的通信的一个或多个兼容的接收器。为了说明的简单，在图1A中没有示出接收器。

服务器102可以包括至少一个处理器108。在涉及多个服务器(例如，服务器群)的实施例中，处理器108可以包括一个或多个专用处理单元、专用集成电路(Application-Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable GateArray，FPGA)、或者与至少一个非暂时性处理器可读存储器110耦合的各种其它类型的处理器或处理单元，该非暂时性处理器可读存储器110被配置用于存储处理器可运行代码。当处理器可运行代码由处理器108执行时，处理器108可以执行各种不同的指令(例如，确定安装在一个或多个车辆104中的一个或多个ECU是否需要更新等)。当确定安装在一个或多个车辆104中的一个或多个ECU需要更新时，处理器108还可以执行指令以生成ECU的更新包。如下面所讨论的，处理器108还可以执行各种其它功能。

可以设想，服务器102可以被配置为服务于各种类型的用户。例如，汽车制造商可以利用服务器102来生成和展示对安装在由汽车制造商制造的车辆上的ECU的软件更新。在另一示例中，组件制造商(例如，ECU开发商，或者其产品使用ECU的制造商)可以利用服务器102来生成和展示对由该组件制造商生产或维护的ECU的软件更新。在又一示例中，服务提供商(例如，经销商或服务中心)可以利用服务器102来更新安装在服务提供商正在服务的车辆上的ECU。应当理解，虽然在图1A中仅描绘了一个服务器102，但是这种描绘仅仅是示例性的，并不意味着限制。可以设想，在不脱离本公开的精神和范围的情况下，可以利用多于一个的服务器102，并且不同的用户可以利用不同的服务器102来生成和展示对ECU的软件更新。

图1B是其中可以生成和监测增量文件和软件更新的系统环境的示例性图示。如图所示，生产工具链122可以是用于开发和分发在车辆ECU(例如，ECU 112)上运行的软件的一组编程系统或工具。生产工具链122可以包括用于开发和实施车辆ECU上的软件的软件组件(例如，编译器、链接器、库等)。如下面进一步讨论的，本公开的实施例涉及生成用于软件更新的增量文件，并且可以基于来自生产工具链122的信息来生成。例如，如下面所讨论的，用于构建增量文件(例如，结合图3)的映射文件、源和二进制数据元素可以来自生产工具链122。软件更新可以被开发为增量文件124，其可以通过空中传送给车辆，如结合图1A进一步讨论的。

图1B还示出了依赖性管理系统126、故障分析系统128、更新管理系统130和报告系统132。在下面讨论的各种实施例中，软件版本之间的依赖性可以被表示为映射文件，该映射文件定义了软件中的功能和实体之间的关系和依赖性、软件的大小、特定存储器地址、对应于存储器位置的特定功能或命令等。此外，依赖性管理系统126可以标识ECU之间的依赖性。例如，当对一个ECU运行软件更新时，该更新可能使得ECU不能与一个或多个其它ECU通信(或不正确地通信)。例如，如果软件更新影响ECU的网络地址、ECU将使用的通信协议、ECU的输入或输出通信策略、来自ECU的通信的报头或有效载荷、来自ECU的通信的定时或ECU的功能的各种其它属性，则可能发生这种情况。为了防止当在ECU上执行软件更新并且其它相互依赖的ECU受到影响时出现冲突，依赖性管理系统126可以被配置为维护ECU之间的依赖性的列表或映射。列表或映射可以标识相互依赖的ECU，并且还可以进一步指定它们相互依赖的原因(例如，预期或要求的数据通信的特定格式、特定的网络地址、特定的通信定时要求等)。该信息可以由依赖性管理系统126维护，并且可以周期性地更新(例如，从服务器102)。

此外，如下面所讨论的，在ECU的操作中可以检测各种异常、错误和故障。这种数据和用于检测这种事件的算法可以由故障分析系统128管理。更新管理系统130可负责确定何时应开发或传输ECU软件更新、哪些车辆或特定ECU应接收更新、以及各种其它类型的信息。报告系统132可以被配置为从车辆接收更新(例如，观测到的ECU的活动)或者向车辆传送报告(例如，关于要执行的更新)。在一些实施例中，依赖性管理系统126、故障分析系统128、更新管理系统130和报告系统132可以在服务器102中实施，或者单独地实施。

图1C是(例如，车辆104-a、104-b、104-c、104-d或104-e中的)车辆通信网络中的架构的图示。例如，远程信息处理控制单元(Telematic Control Unit，TCU)134可以被集成到网络中，以执行对车辆的各种跟踪功能。在一些实施例中，TCU 134可以包括集成的或单独的远程通信收发器(例如，蜂窝网络、WiFi、卫星等)、全球定位系统(Global PositioningSystem，GPS)收发器以及用于与车辆通信网络的其它组件接口的控制器。网络还可以包括网关136，网关136可以是与车辆的外部网络(例如，服务器102)和内部网络通信的中心点。在一些实施例中，网关136可以与控制车辆中的ECU 112的一个或多个操作的协调器(下面进一步讨论)接合(interface)。网络还可以包括车载诊断端口138，车载诊断端口138可以是允许有线连接到车辆网络用于诊断、维护和其它功能的物理端口。此外，车辆网络可以包括各种ECU，诸如ECU 112、112a、112b、112c等。如图所示，ECU 112可以配置有用于故障检测和停机预测140、到ECU软件的先前版本的集成回滚142、以及统一诊断服务(UnifiedDiagnostic Service，UDS)更新144、以及其他操作的软件指令。这些功能将在下面进一步讨论。

图2是描绘由服务器102执行以更新示例性ECU 112的软件的示例性ECU软件更新过程的图示。在一些实施例中，该过程可以在车辆中本地执行，而不是在服务器102处执行(例如，通过车辆中管理ECU 118的协调器)。如图2所示，服务器102可以访问关于ECU 112将要使用的新版本的ECU软件(可以被称为软件更新202)和ECU 112使用的当前版本的ECU软件(可以被称为当前软件204)两者的信息。服务器102可以以各种方式访问关于软件更新202的信息。在一些实施例中，负责开发或维护ECU软件的汽车制造商或组件制造商可以提供软件更新202的副本以本地存储在服务器102上。在一些实施例中，用于开发软件更新202的工作站可以被配置为充当服务器102。在一些实施例中，汽车制造商或组件制造商也可以将软件更新202的副本存储在服务器102可访问的一个或多个网络存储设备中。在一些实施例中，软件更新202可以作为单片文件提供。在一些实施例中，软件更新202可以作为与其它文件相互依赖的文件来提供。

服务器102可以以各种方式访问关于ECU 112使用的当前软件204的信息。在一些实施例中，服务器102可以向ECU 112查询(例如，经由通信信道106)其软件版本号。在一些实施例中，服务器102可以请求直接访问其中存储了ECU 112使用的当前软件204的存储器设备(例如，闪存、RAM、ROM等)120。在一些实施例中，服务器102可以保存部署到ECU的软件版本的记录，并使用该记录来确定ECU 112使用的当前软件204的版本。可以设想，虽然具体实施方式可以变化，但是只要服务器102可以访问关于软件更新202和当前软件204两者的信息，服务器102就可以比较软件更新202和当前软件204两者的属性，并且生成表示软件更新202的属性和当前软件204的对应属性之间的差异的增量文件，如下面进一步讨论的。

图3是描绘由服务器102执行以生成这种增量文件的示例过程的图示。如图3所示，服务器102可以将包括软件更新202的源、二进制代码和映射文件的属性与当前软件204的它们的对应属性进行比较。如上面所讨论的，这些属性可以从生产工具链122直接获得(例如，作为软件构建和部署过程的一部分或后续)。源属性可以标识例如源代码语言、版本、源代码是否是平面的、源代码中引用的对象的数量或类型以及其它属性。二进制属性可以被表示为可执行和可链接格式(Executable and Linkable Format，ELF)代码(例如，带有程序头、段头、数据等)、纯二进制或其它形式。映射文件可以描述软件202和/或204中的功能和实体之间的关系和依赖性、软件的大小、特定存储器地址、对应于存储器位置的特定功能或命令等。

根据它们的源、二进制代码和映射文件属性来表示软件更新202和当前软件204可以被称为“网格”表示，并且表示软件更新202的网格和表示当前软件204的网格之间的比较可以被称为多维(例如，三维差量(或3Diff)比较)。在一些实施例中，也可以使用更少或额外的维度。这种3Diff比较或其它多维比较可用于产生增量文件206，该增量文件206可以包括表示对ECU112的二进制和/或源代码210所做的改变、对ECU 112使用的一个或多个变量212所做的改变以及对ECU 112所引用的存储器地址214所做的改变的数据。值得注意的是，这种3Diff文件可以表示软件更新202和当前软件204之间的差异，使得可以通过仅接收3Diff文件而不是整个软件更新202本身来将当前软件204升级到软件更新202。

图3中还示出了启动代码208，其可以被集成到3Diff文件或增量文件206中。可选地，启动代码208可以是当前软件204的一部分，而不是增量文件206的一部分。例如，在这样的实施例中，启动代码208可以是与ECU及其软件相关联的预先存在的启动或初始化代码。

在一些实施例中，服务器102可以配置启动代码208来初始化增量文件206的运行时库。在一些实施例中，例如，服务器102可以配置启动代码208来更新ECU 112的程序计数器，以跳过包含在当前软件204中的特定代码，并执行包含在增量文件206中的特定代码来代替。例如，如图4所示，启动代码208可以被配置为更新ECU 112的程序计数器，使得ECU112可以跳过包含在当前软件204中的代码段(在图4中被描绘为程序计数器更新“1”)，并执行包含在增量文件206中的代码段来代替(在图4中被描绘为程序计数器更新“2”)。服务器102还可以配置启动代码208来更新ECU 112的程序计数器，使得在执行包含在增量文件206中的代码段之后，程序计数器可以将执行链接回包含在当前软件204中的代码(在图4中被描绘为程序计数器更新“3”)。以这种方式，包含在增量文件206中的代码段可以被放置在存储器120中的任何地方，并且ECU 112的程序计数器可以用于将该代码段加载到ECU 112的存储器(例如，闪存、RAM等)中用于执行。换句话说，包含在增量文件206中的代码可以是与位置无关的，并且可以被放置在存储器120中，而不需要ECU 112擦除存储器120的任何现有内容。此外，启动代码208可以被配置为从3Diff文件或增量文件206中提取增量数据，并将其存储在ECU 112的存储器(例如，闪存、RAM、ROM等)上。数据可以包括在软件202/204的运行时期间使用的数据。启动代码还可以确定是否需要擦除ECU 112中存储器的旧内容(例如，由于存储空间几乎满了)。

应当理解，使用ECU 112的程序计数器来将包含在增量文件206中的代码加载到ECU 112的存储器中仅仅是作为示例呈现的，并不意味着限制。在一些实施例中，作为替代或结合，引导(bootstrap)加载器(例如，驻留在ECU 112的存储器中的程序)可以被用来将包含在增量文件206中的代码加载到ECU 112的存储器中。应当理解，在不脱离本公开的精神和范围的情况下，也可以使用其它技术来将包含在增量文件206中的代码加载到ECU 112的存储器中用于执行。

还应当理解，虽然图4描绘了将ECU 112的程序计数器从包含在当前软件204中的一个代码段重定向到包含在增量文件206中的另一代码段，但是这种描绘仅仅是示例性的。可以设想，包含在增量文件206中的代码改变210可以表示对包含在当前软件204中的一个以上的代码段所做的改变。例如，如图5所示，增量文件206可以包括对被称为“符号1”、“符号2”和“符号3”的三个不同代码段的代码改变。可以设想，这些代码改变可以以类似于上面描述的方式来处理。也就是说，包含在增量文件206中的启动代码(或者，可选地，包含在当前软件204中的启动代码)可以更新ECU 112的程序计数器，以跳过包含在ECU 112的当前软件204中的特定代码段(即，符号)，并将包含在增量文件206中的对应代码段(即，对应的符号)加载到存储器(例如，闪存、RAM等)中来代替执行。

在一些实施例中，ECU 112可以利用虚拟文件系统(VFS)230来管理符号。如本文所讨论的，VFS 230可以是各种不同类型的虚拟文件系统、数据库或列表。VFS 230可以提供软件202/204的抽象，并且可以表示3Diff文件的元素(例如，源、二进制和映射文件属性)。在一些实施例中，ECU 112可以利用VFS 230来跟踪符号的不同版本。例如，如图6所示，如果第二增量文件216(表示在第二软件更新中做出的改变)对ECU 112可用，并且如果第二增量文件216包含对符号1和符号2做出的代码改变的版本2，则ECU 112可以利用VFS 230来跟踪符号的不同版本，并确定要用于执行的正确版本。如果第三增量文件226(表示在第三软件更新中做出的改变)对ECU 112可用，并且如果第三增量文件226包含对符号1做出的代码改变的版本3，则ECU 112也可以利用VFS 230来跟踪符号1的版本3，如图7所示。

在一些实施例中，如果需要，ECU 112可以利用VFS 230来回滚对ECU 112的软件的特定改变。例如，在检测到ECU 112的性能中的特定异常(其细节将在后面描述)时，服务器102可以确定符号1的版本3应该被呈现为不可执行(或禁用)并且ECU软件应该被恢复回先前版本(例如，第二软件更新)。如图8所示，服务器102可以通过提示ECU 112回滚到第二软件更新，并且ECU 112可以进而通过更新ECU 112中对应于这些符号的存储器地址，利用VFS230来重新建立符号1、版本2(并且禁用符号1、版本3)，来实现这一点。实际上，符号1的版本3可以从ECU 112的存储器(例如，闪存、RAM等)中移除并且符号1的版本2可被加载到ECU112的存储器中来代替执行。然而，值得注意的是，不需要删除符号1的版本3并下载符号1的版本2的整个副本。相反，如下面进一步讨论的，ECU 112可以简单地接收标识对ECU 112的存储器的、需要被更新(基于源、二进制和映射文件属性)以完成到符号1的版本2的恢复的更新的增量文件206。使用这种技术，减少了到ECU 112的传输的带宽，并且也节省了ECU112中的存储空间。这种技术将在下面进一步讨论。

现在回到图3。注意，除了处理代码改变之外，服务器102还可以配置启动代码208来处理对ECU 112使用的变量所做的改变以及对ECU 112所引用的存储器地址所做的改变。具体地，在一些实施例中，服务器102可以配置启动代码208以从增量文件206提取变量改变数据212，并将提取出的变量数据(如果有的话)放置到ECU 112的存储器(例如，闪存、RAM等)中。如上面提到的，启动代码208可以位于增量文件206本身中，或者位于当前软件204中。服务器102还可以配置启动代码208以包括从ECU 112的存储器中删除旧的(过时的)变量数据的指令。服务器102还可以配置启动代码208以从增量文件206中提取存储器地址改变数据214(如果有的话)，并相应地更新ECU 112中的存储器地址。以这种方式，服务器102可以简单地将增量文件206放置到存储器120中而不必对当前软件204做出任何改变，并且让ECU 112执行包含在增量文件206或当前软件204中的启动代码208，以将当前软件204和增量文件206链接在一起，从而形成软件更新202的功能等同物，而不需要重启ECU 112。

在一些实施例中，增量文件206可以被实施为可以容易地由ECU 112处理的标准十六进制或二进制文件(或其它类型，诸如S Record、Motorola^TM等)。在一些实施例中，当增量文件206被放置到存储器120中时，ECU 112可以继续其操作(例如，继续执行包含在当前软件204中的代码)。在一些实施例中，在完成上述更新过程之后，ECU 112可以对存储器120进行碎片整理。然而，可以设想，对存储器120进行碎片整理可能只是偶尔需要，而不是每次软件更新都需要。

随着后续软件更新变得可用，更新过程可以被重复多次。如图9所示，假设在时间T1处，第一软件更新可用，并且服务器102生成增量文件206并将增量文件206提供给ECU112。一旦在ECU 112处接收到增量文件206(并存储到存储器120中)，ECU 112可以基于包含在增量文件206中的启动代码来执行增量文件206，并将增量文件206链接到ECU 112的软件204，如上所述。如果在时间T2处，第二软件更新变得可用于替换第一软件更新，则服务器102可以重复上述过程(例如，将第二软件更新与ECU 112的软件204进行比较，生成第二增量文件216，并将第二增量文件216提供给ECU112)。一旦在ECU 112处接收到第二增量文件216(并存储到存储器120中)，ECU 112可以基于包含在第二增量文件216中的启动代码来执行第二增量文件216，并将第二增量文件216链接到ECU 112的软件204。类似地，如果在时间T3处，第三软件更新变得可用，则服务器102可以向ECU 112提供第三增量文件226，并且ECU112可以相应地将第三增量文件226链接到ECU 112的软件204。

图9中还示出了服务器102回滚特定软件更新的能力。例如，当在时间T4处检测到特定异常(其细节将在后面描述)时，服务器102可以确定第三软件更新应该被呈现为不可执行并且ECU软件应该恢复回先前版本(例如，第二软件更新)。服务器102可以通过提示ECU112移除第三增量文件226和ECU 112的软件204之间的链接(例如，将包含在增量文件226中的代码改变呈现为不可执行，如前面参考图8所述)并重新执行包含在第二增量文件216中的启动代码，以重新建立第二增量文件216和ECU 112的软件204之间的链接，来实现这一点，如图9所示。

在一些实施例中，ECU 112可以被配置为在回滚操作之后将第三增量文件226保存在存储器120中。将第三增量文件226保存在存储器120中可以允许ECU 112稍后重新激活第三软件更新(如果需要)。

在一些实施例中，服务器102可以有目的地将第三增量文件226推送进存储器120中，作为为ECU 112准备将来的更新的一种方式。例如，当第三增量文件226被推送进存储器120时，服务器102可以指示ECU 112暂时绕过包含在第三增量文件226中的启动代码。因此，第二增量文件216和ECU 112的软件204之间的链接可以适当地保持，直到服务器102指示ECU 112执行包含在第三增量文件226(或在当前软件204)中的启动代码，该启动代码然后可以将第三增量文件226链接到ECU 112的软件204并完成第三软件更新的部署。可以设想，这种操作可以被称为前滚(roll forward)，其可以被用作协调ECU软件更新的推出的技术。

然而，应当注意，由于存储器120的存储容量，可以存储在存储器120中的增量文件的数量可能是有限的。因此，在一些实施例中，当ECU 112确定存储器120的利用率高于阈值(例如，75％或90％满)时，ECU 112可以被配置为标识用于删除的存储在存储器120中的特定内容。在一些实施例中，ECU 112可以基于它们对应的创建日期、版本号、文件大小等来标识用于删除的内容。例如，长时间未被使用的旧增量文件可能是用于删除的好候选。在一些实施例中，ECU 112也可以选择完全替换其存储器内容。例如，替代于保存其原始软件加上多年来接收的多个增量文件，ECU 112可以决定擦除存储器120的全部内容，并用最新的ECU软件的干净副本来替换。ECU 112可以继续将上述基于增量文件的更新过程用于将来的更新。

现在总体参考图1A。注意，虽然上面的描述提供了各种示例来说明服务器102经由通信信道106向车辆104提供软件更新的有效技术，但是车辆104也可以利用通信信道106向服务器102提供信息，以进一步增强软件更新过程。

例如，在一些实施例中，车辆104-b可以包括至少一个处理器114，该处理器114与被配置用于存储处理器可运行代码的至少一个非暂时性处理器可读存储器116耦合。当处理器可运行代码由处理器114执行时，处理器114可以执行指令来监测ECU 112的实时处理活动并标识ECU异常。在一些实施例中，处理器114可以向服务器102和/或其它车辆104提供关于ECU异常的信息。

出于说明的目的，被配置为监测ECU 112的实时处理活动并向服务器102和/或其它车辆104提供关于ECU异常的信息的处理器114可以被称为协调器114。在一些实施例中，协调器114可以被实施为与ECU 112分离的单元。然而，可以设想，在不脱离本公开的精神和范围的情况下，协调器114和ECU 112可以共享特定硬件组件。在另外的实施例中，协调器114可以被配置为执行机器学习或人工智能功能(例如，基于来自ECU、来自车队中的ECU等的数据)，如下面进一步讨论的。

在一些实施例中，协调器114可以被配置为访问与ECU 112的处理活动相关的历史数据。在一些实施例中，历史数据可以由ECU 112或协调器114预先记录在存储器116中。历史数据可以表示ECU 112的预期处理活动。协调器114可以将实时处理活动数据与历史数据进行比较，以标识ECU 112的实时处理活动中的一个或多个异常。在一些实施例中，协调器114可以实施各种类型的统计模型来执行比较。在一些实施例中，协调器114可以实施各种类型的数据处理技术(包括机器学习技术)来标识异常。

在一些实施例中，协调器114可以被配置为向服务器102报告其发现(例如，经由通信信道106)。可选地或附加地，在一些实施例中，当标识出一个或多个异常时，协调器114可以为ECU 112实施一个或多个控制动作。控制动作可以包括，例如，发出与ECU 112相关联的警报，阻止从ECU 112发送的指令，或者向ECU 112发出提示并请求ECU 112从执行一个版本的ECU软件调整到执行另一个版本(例如，将运行在ECU上的ECU软件的版本回滚到ECU软件的先前版本)。

可以设想，根据所公开的实施例配置的协调器114能够检测各种类型的异常。例如，在一些实施例中，检测到的异常可以对应于由ECU 112使用的特定存储器位置。如果ECU112尝试访问特定存储器位置之外的存储器位置，则协调器114可以将这种活动标识为异常。在一些实施例中，检测到的异常可以对应于由ECU 112使用的存储器位置的特定序列。如果ECU 112尝试以与特定序列不兼容的顺序访问存储器位置，则协调器114可以将这种活动标识为异常。在一些实施例中，检测到的异常可以对应于流入或流出ECU 112的数据中的至少一个峰值。如果流入或流出ECU 112的数据异常高，则协调器114可以报告异常。在一些实施例中，检测到的异常可以对应于由ECU 112的一个或多个处理器正在处理的数据中的至少一个峰值。如果由ECU 112的一个或多个处理器正在处理的数据异常高，则协调器114可以报告异常。在一些实施例中，检测到的异常可以对应于ECU 112的功耗中的至少一个异常。如果ECU 112的功耗异常高，则协调器114可以报告异常。

在一些实施例中，协调器114可以被配置为监测除了ECU 112之外的其它ECU。在一些实施例中，协调器114可以被配置为监测车辆104-b中的多个ECU的实时处理活动。例如，在一些实施例中，协调器114可以被配置为接收与被认为与ECU 112可比的至少一个其它ECU 118的处理活动相关的可比数据。

可以设想，ECU 118和ECU 112可以通过它们的制造商或开发商被认为是可比的。基于它们的控制功能和/或与运行在ECU 118和ECU 112上的ECU软件相关联的规则，ECU118和ECU 112也可以被认为是可比的。例如，如果ECU 118和ECU 112已经确立了它们对应的执行序列足够相似，则ECU 118和ECU 112可以被认为是可比的。在另一示例中，如果ECU118和ECU 112都遭受类似的恶意执行序列，则ECU 118和ECU 112可以被认为是可比的。在又一示例中，如果ECU 118和ECU 112的映射文件足够相似，则ECU 118和ECU 112可以被认为是可比的。在再一示例中，协调器114可以与位于其它车辆104上的处理器通信(例如，经由通信信道106)，以观测其它车辆104可能认为哪些ECU是可比的。协调器114然后可以基于其对其它车辆104的观测来确定位于车辆104-b中的哪些ECU可以被认为是可比的。

在一些实施例中，协调器114可以被配置为将从ECU 112接收的实时处理活动数据与从ECU 118接收的可比数据进行比较，以标识ECU 112的实时处理活动中的一个或多个异常。在一些实施例中，从ECU 118接收的可比数据可以表示从ECU 118接收的实时处理活动数据。可选地或附加地，在一些实施例中，从ECU 118接收的可比数据可以包括从ECU 118获得的先前记录的活动数据。

在一些实施例中，协调器114可以实施各种类型的统计模型，以执行从ECU 112接收的实时处理活动数据和从ECU 118接收的可比数据之间的比较。在一些实施例中，协调器114可以实施各种类型的数据处理技术(包括机器学习技术)来标识异常。在一些实施例中，协调器114可以被配置为向服务器102报告其发现。可选地或附加地，在一些实施例中，当标识出一个或多个异常时，协调器114可以为ECU 112实施一个或多个控制动作。

在一些实施例中，协调器114可以被配置为电子轮询(electronically poll)车辆104-b中的ECU，以确定ECU是否在正确地响应轮询。协调器114然后可以标识与车辆104-b中的一个或多个ECU相关联的一个或多个ECU错误或故障。故障的一个示例可以是ECU在每时间间隔执行某操作不同于预期或允许的次数。如果标识出ECU错误或故障，则协调器114还可以收集与ECU的操作和标识出的ECU错误相关的数据。协调器114可以从车辆104-b向服务器102发送标识ECU和标识出的ECU错误的报告。服务器102可以将该报告用于各种目的，包括标识错误和开发错误修复。

应当理解，虽然在上面的示例中使用了术语“协调器”，但是该术语并不意味着是限制性的。可以设想，协调器可以被配置为电子轮询车辆中的ECU，以确定ECU是否在正确地响应轮询。此外，协调器114可以利用机器学习或人工智能技术来确定ECU是否在正确地运行(例如，在可接受或预期的行为范围内运行)。例如，协调器114可以被配置为监测ECU(或多个ECU)中靠前的功能(例如，前10或前100个功能)，并开发观测到的功能的模型或映射。当检测到与该模型或映射的偏差时，可以宣布异常。在一些实施例中，协调器114可以被实施为特定的ECU(例如，图1中的ECU 112)，而其它ECU被配置为向协调器114ECU报告(例如，经由推送或拉取)数据。以这种方式，协调器114ECU可以收集将在机器学习或人工智能中使用的关于其它ECU的观测到的和预期的功能的数据。

在一些实施例中，协调器114可以参与车辆中的ECU的预测性维护或自愈过程。这些方法可以基于分布式人工免疫系统(Artificial Immune System，AIS)框架。具体地，遍及车辆的ECU可以被配置为向协调器114(或另一个AIS配置的ECU)报告(例如，经由推送或拉取)关于它们的操作和功能的数据，用于机器学习和人工智能。协调器114(或另一个AIS配置的ECU)可以对接收的数据执行算法，以检测软件异常、错误(例如运行时错误)和故障(例如，漂移)。这种架构可以是高效和低影响的，因为它在许多ECU之间广泛地分发ECU报告，并且仍然能够跟踪ECU性能的许多不同参数。此外，协调器114(或另一个AIS配置的ECU)可以自主地和自适应地执行分析，反映车辆内ECU操作的连续改变的本质。基于协调器114(或另一个AIS配置的ECU)的机器学习或人工智能功能，可以建议或自动实施推荐的改变以维护车辆ECU的健康(例如，执行软件回滚、执行软件更新等)。在一些实施例中，机器学习或人工智能功能在服务器(例如，服务器102)处执行，并且可以为整个车队(例如，共享相似的ECU、相似的软件版本等的车队)提供推荐的改变。

协调器114(或另一个AIS配置的ECU)的系统架构可以是多层的。在一些实施例中，协调器114或服务器102充当中心节点，向其报告运行或功能数据的各个ECU是子节点或边缘节点。第一层(例如，层1)可以执行对ECU行为的低轮廓(low-profile)监测。例如，这可能涉及应用机器学习模型或人工智能算法来分析各个ECU或ECU组的活动。这可以考虑到ECU存储器足迹、中央处理器处理活动、调用的函数、调用的函数序列等)。第二层(例如，层2)可以按需操作。例如，如果机器学习或人工智能层检测到ECU的操作行为中的潜在异常，则可以到达层2，这可以涉及对所讨论的ECU的进一步分析(例如，存储器堆栈分析、向协调器114或服务器102报告关于ECU异常的信息等)。类似地，在操作的第三层(例如，层3)中，ECU操作的样本(例如，被调用的存储器位置、软件版本、增量文件版本、软件副本等)可以被传输回协调器114或服务器102用于进一步分析。在操作的第四层(例如，层4)中，可以确定对所讨论的ECU或ECU组执行控制动作。这可以包括，例如，将软件回滚到先前版本(例如，基于先前版本的增量文件)，激活ECU的安全模式(例如，阻止网络通信，调节功能等)，或ECU的其它形式的控制。

应当理解，协调器114可以利用位于车辆104-b中的一个或多个处理器114来实施。在一些实施例中，协调器可以在处理器114或车辆中的单独的处理器上实施。在一些实施例中，协调器可以远程地实施(例如，经由服务器102)。为了说明的简单，下面的描述将引用处理器，该处理器被配置为作为协调器电子轮询车辆中的ECU，以确定ECU是否在正确地响应轮询，或者执行机器学习或人工智能功能。

在一些实施例中，协调器可以通过向ECU发送请求消息来轮询车辆104-b中的ECU，并等待ECU提供一个或多个响应消息。协调器可以指例如检测程序是否继续运行的处理器(例如，ECU处理器)中的集成硬件计数器或监测器。当检测到对轮询的响应失败时，协调器可以确定ECU已经执行或导致了错误或故障。如上面所讨论的，错误和故障可以包括运行时错误、堆栈上溢错误、应用执行轮廓的“漂移”(例如，变得更慢、更快或在更长或更短的时段内发生)等。

在一些实施例中，协调器可以轮询车辆104-b中的多个ECU，以确定ECU是否正在执行对车辆104-b的一个或多个硬件组件具有潜在影响的ECU软件。例如，如果在更新ECU 112之后，与变速器交互的多个ECU开始表现出错误的行为，协调器可以确定ECU 112的软件更新对车辆104-b的变速器具有潜在影响。协调器还可以收集来自各种ECU的报告数据(例如，包括ECU标识符和/或指示ECU的最后已知轮询的数据)以及来自车辆104-b的各种硬件组件(例如，包括变速器)的报告数据。协调器还可以基于报告的数据执行统计分析、机器学习或人工智能功能，如下面进一步讨论的。

在一些实施例中，协调器可以确定ECU中的潜在影响或异常是否有害。例如，如果协调器基于报告的数据确定在正常操作期间变速器的平均温度增加了几度，则协调器可以确定对变速器的潜在影响是有害的。可选地或附加地，在一些实施例中，协调器可以被配置为向服务器102提供报告的数据，并让服务器102(或其用户)确定潜在影响是否有害。

在一些实施例中，协调器可以基于报告的数据来确定ECU的停机概率。协调器可以基于统计模型或过去行为，包括下面讨论的机器学习和人工智能技术，来做出该确定。在一些实施例中，协调器可以被配置为向服务器102报告其确定。在进一步的实施例中，如下面所讨论的，当确定潜在影响是有害的时，或者当停机概率超过特定阈值时，协调器可以为ECU 112实施一个或多个控制动作。

现在总体参考图1A所示的车辆网络100。可以设想，除了(或者代替)由位于车辆104上的处理器114执行之外，由上述协调器提供的功能中的一些可以通过网络106来执行。例如，在一些实施例中，服务器102可以被配置为经由通信信道106从一个或多个报告车辆104接收ECU活动数据。在一些实施例中，报告车辆104可以包括作为组被监测的车辆。在一些实施例中，报告车辆可以包括具有共同类型的ECU的车辆集合(例如，如果车辆104-a、104-b和104-c都具有相同类型的ECU，则车辆104-a、104-b和104-c可以作为组被监测)或共同的软件版本。

在一些实施例中，ECU活动数据可以对应于在车辆组(例如，以上示例中的车辆104-a、104-b和104-c)中运行的一个或多个ECU的实际操作。在一些实施例中，服务器102可以被配置为基于ECU活动数据来确定影响车辆104-a、104-b和104-c的软件漏洞。在一些实施例中，服务器102可以实施各种类型的统计模型来基于ECU活动数据来确定软件漏洞。例如，在一些实施例中，服务器102可以基于接收的ECU活动数据和预期的(或历史的)ECU活动数据之间的偏差来确定软件漏洞。在一些实施例中，服务器102可以实施各种其它类型的数据处理技术(包括机器学习技术)来确定软件漏洞。

在一些实施例中，如果确定存在影响车辆104-a、104-b和104-c的软件漏洞，则服务器102可以被配置为标识ECU软件更新。服务器102还可以生成并发送被配置为更新受影响的车辆104-a、104-b和104-c的ECU上的软件的增量文件。可以设想，服务器102可以根据上述过程来生成增量文件。还可以设想，车辆104-a、104-b和104-c可以处理增量文件并执行如上所述的ECU软件更新过程。

在一些实施例中，服务器102还可以被配置为确定可能受到上面标识的软件漏洞影响的第二车辆集合。第二车辆集合可以包括不属于最初向服务器102报告ECU活动数据的车辆组的一部分的车辆104-d和104-e(例如，车辆104-d和104-e可能在早些时间不能连接到服务器102)，但是仍然可以包含应该被更新的ECU。服务器102可以基于部署的ECU版本号的记录或基于对这些车辆的查询来标识这些车辆(例如，服务器102可以要求所有车辆104报告它们的ECU软件版本号、3Diff版本或其它标识符)。在一些实施例中，服务器102可以被配置为向正在使用应该被更新的ECU的所有车辆发送增量文件。在一些实施例中，服务器102可以被配置为将增量文件推送到所有车辆104，作为重新校准安装在车辆104中的ECU的方式。

可以设想，位于车辆104上的一个或多个处理器114在从服务器102接收到增量文件时，可以将增量文件放置到对应ECU的存储器设备中，并且在不中断ECU的操作的情况下执行更新。然而，还可以设想，在某些情况下，位于车辆104上的一个或多个处理器114可以决定适时地执行更新。

例如，在一些实施例中，位于车辆104-b上的处理器114可以接收指示需要更新在车辆104-b中的ECU 112上运行的软件的无线传输。处理器114可以监测车辆104-b的运行状态，以确定车辆104-b是否处于禁止ECU软件更新的第一运行模式。当车辆104-b不能与服务器102建立稳定连接时，车辆104-b可以处于第一运行模式。当无线通信强度低于阈值水平时，车辆104-b也可以处于第一运行模式。此外，当车辆处于受限区域中或者正在执行特定操作(例如，以高于阈值的速度行驶)时，车辆104-b可以处于第一运行模式。应该理解，上面呈现的示例是为了说明的目的，并且不意味着限制。可以设想，在不脱离本公开的精神和范围的情况下，车辆104-b可以由于各种其它原因而处于第一运行模式。

在一些实施例中，如果处理器114确定车辆104-b处于第一运行模式，则处理器114可以选择延迟ECU软件更新过程。在一些实施例中，处理器114可以将接收的增量文件存储在存储器116中。在一些实施例中，处理器114可以丢弃增量文件(稍后当处理器114准备好安装ECU软件更新时可以请求该增量文件)。

处理器114可以继续监测车辆104-b的运行状态，以确定车辆104-b是否转换到允许ECU软件更新的第二运行模式。在一些实施例中，处理器114可以根据预先建立的间隔(例如，每10分钟)继续重复监测车辆104-b的运行状态。当例如车辆104-b进入预定安全运行条件中的一个时，诸如以低于阈值水平的速度行驶、运行低功率或断电状态、在预选的环境条件下运行、怠速等，处理器114可以确定车辆104-b处于第二运行模式。当车辆104-b可以与服务器102建立稳定连接时，处理器114还可以确定车辆104-b处于第二运行模式。例如，当无线通信强度达到强度阈值以上或者与服务器102的网络连接的误码率低于阈值时，处理器114可以确定车辆104-b处于第二运行模式。

一旦处理器114确定车辆104-b处于第二运行模式，处理器114可以启用ECU软件更新过程，该过程可以如上所述进行。如果处理器114在其决定延迟ECU软件更新过程时将接收的增量文件的副本存储在存储器116中，则处理器114可以从存储器116中检索接收的增量文件的副本，并将增量文件写入ECU 112的存储器120中。如果处理器114在其决定延迟ECU软件更新过程时丢弃了增量文件，则处理器114可以向服务器102发送消息以请求增量文件的另一副本。处理器114可以从服务器102接收回复消息中的增量文件，并将增量文件写入ECU 112的存储器120中，并执行如上所述的更新过程。

应当理解，虽然处理器114可以有一些关于ECU软件更新过程的延迟的酌处权(discretion)，但是在一些实施例中，这种酌处权可能不是绝对的。例如，在一些实施例中，处理器114可以从服务器102接收指示将在超驰状态下执行ECU软件更新的无线传输。如果接收到具有超驰状态的ECU软件更新，则处理器114可能不能行使其酌处权，并且可能必须更新ECU软件，而不管车辆104-b是否处于第一运行模式。可以设想，这种具有超驰状态的更新可以用于立即部署关键的ECU更新，而不会延迟。

类似地，如前所述，利用根据所公开的实施例配置的增量文件的ECU软件更新过程可以允许ECU被更新而不必重启。然而，在一些实施例中，服务器102可以指示给定的ECU软件更新将通过强制重启来执行。如果接收到带有重启请求的ECU软件更新，则处理器114可以指示ECU运行如上所述的更新，随后强制重启。

从上面的描述可以理解，利用根据所公开的实施例配置的增量文件可以提高ECU更新过程的效率。这些增量文件的大小更小，因为它们不需要包括整个ECU软件。这些增量文件也可以直接被写入ECU存储空间，这可以减少存储空间和功率两者的消耗。这些增量文件也可以被实施为自包含的包，包括代码改变、变量改变和存储器地址改变。这些增量文件还可以包含可以由ECU运行的启动代码，这允许增量文件为与位置无关的，并允许ECU在不必改变其原始软件或不中断其当前操作的情况下执行更新。

根据所公开的实施例配置的虚拟文件系统(VFS)也可以提高ECU更新过程的效率。VFS可以用于管理和跟踪ECU软件的不同版本，并且可以支持上述更新和回滚操作。此外，应当注意，使用根据所公开的实施例配置的VFS来管理和跟踪ECU软件的不同版本可能需要非常少的空间开销，因为只需要跟踪版本之间的差异(增量)，而不需要记录重复的代码。

此外，应当注意，利用由根据所公开的实施例配置的VFS管理的增量文件可以消除在更新之后重启ECU的需要。具体地，根据所公开的实施例配置的增量文件可以同时实施代码改变、变量改变和存储器地址改变，从而有效地将原始ECU软件和增量文件链接在一起，以形成更新的ECU软件的功能等同物，而不需要重启。

可以设想，根据所公开的实施例配置的ECU软件更新过程也可以用于更新虚拟ECU。虚拟ECU可以指在虚拟机或驻留在共享硬件资源上的管理程序上实施的ECU。可以设想，在不脱离本公开的精神和范围的情况下，可以利用基本相同的ECU软件更新过程来更新虚拟ECU软件。

现在参考图10，示出了示出用于生成用于更新车辆中的ECU上的软件的更新包的过程1000的示例性流程图。根据上述实施例，过程1000可以在图1A所示的系统100中实施。例如，过程1000可以由服务器102执行。如上面所讨论的，更新包(例如，基于诸如源、映射、二进制的软件属性)可以从生产工具链122获得。此外，结合生成更新包，可以参考依赖性管理系统126。具体地，可以检查依赖性管理系统126，以确定新的更新包是否与车辆中与其它ECU相互依赖的ECU相关联，如果是，确定是否也应该为相互依赖的ECU运行软件更新。如上面所讨论的，依赖性管理系统126可以维护ECU的列表或映射，使得在执行软件更新之前可以确认ECU之间的相互依赖性。在一些实施例中，列表或映射也基于生产工具链122。

在步骤1002处，过程1000可以访问要存储在车辆中的ECU(例如，车辆104-b中的ECU 112)上的软件更新(例如，图2中所示的软件更新202)的多个属性。在步骤1004处，过程1000可以访问存储在车辆中的ECU上的当前软件(例如，存储在车辆104-b中的ECU 112上的当前软件204)的多个对应属性。在步骤1006处，过程1000可以将软件更新的属性与当前软件的对应属性进行比较。在步骤1008处，过程1000可以生成表示软件更新的属性和当前软件的对应属性之间的差异的增量文件。在步骤1010处，过程1000可以将启动代码集成到增量文件中。在一些实施例中，启动代码可以使得增量文件能够在车辆的ECU中自执行。

在一些实施例中，在步骤1006处，过程1000可以将包括软件更新的源、二进制代码和映射文件的属性与当前软件的它们的对应属性进行比较。如上面所讨论的，根据它们的源、二进制代码和映射文件属性来表示软件更新和当前软件可以被称为“网格”表示，并且表示软件更新的网格和表示当前软件的网格之间的比较可以被称为三维差量(或3Diff)比较。在一些实施例中，被比较的属性可以至少部分地基于用于开发软件更新的编程语言、至少部分地基于软件更新的二进制文件分辨率、或者至少部分地基于与软件更新相关联的映射文件来标识。

在一些实施例中，在步骤1008处，过程1000可以利用这种3Diff比较来产生增量文件，该增量文件可以包括表示对ECU的二进制和/或源代码所做的改变、对ECU所使用的一个或多个变量所做的改变以及对ECU所引用的存储器地址所做的改变的数据。例如，在一些实施例中，在步骤1008-1处，过程1000可以将第一网格应用于软件更新，并且在步骤1008-2处，过程1000可以将第二网格应用于存储在ECU上的当前软件。第一网格可以在一个或多个维度上表示软件更新，该一个或多个维度包括与软件更新相关联的二进制数据、与软件更新相关联的源属性和/或与软件更新相关联的映射文件。在步骤1008-3处，过程1000可以基于第一网格和第二网格的比较来标识软件更新的属性和当前软件的对应属性。

在一些实施例中，在步骤1010处，过程1000可以集成被配置为初始化增量文件的运行时库的启动代码。在一些实施例中，过程1000可以配置启动代码来更新ECU的程序计数器，以跳过包含在当前软件中的特定代码，而执行包含在增量文件中的特定代码来替代。启动代码可确定是否需要擦除ECU中的存储器的旧内容。此外，启动代码可以从增量文件中提取变量数据，并将变量数据放置到ECU可访问的随机存取存储器中。在一些实施例中，启动代码可以提取用于更新存储器地址的代码，并更新ECU中的存储器地址。

现在参考图11，示出了示出用于在车辆中接收和集成增量文件的过程1100的示例性流程图。根据上述实施例，过程1100可以在图1A所示的系统100中实施。例如，过程1100可以由车辆104-b中的ECU 112执行。

在步骤1102处，过程1100可以接收增量文件(例如，增量文件206)，该增量文件包括对应于用于ECU(例如，ECU 112)上的软件的软件更新的多个增量(或改变)和用于在ECU中执行增量文件的启动代码(例如，启动代码208)。在步骤1104处，过程1100可以基于启动代码在ECU中执行增量文件。在一些实施例中，可以根据上述实施例配置启动代码，并且在步骤1106处，过程1100可以更新ECU中的存储器地址，以对应于来自增量文件的多个增量。

在一些实施例中，增量文件可以被写入与ECU相关联的存储器设备(例如，如图1A所示的存储器设备120)。在一些实施例中，增量文件可以从存储器设备被引导(bootstrap)到与ECU相关联的随机存取存储器。此外，增量文件可以在不影响ECU的继续操作的情况下或者不重启ECU的情况下由ECU运行。

在一些实施例中，增量文件可以包括要由ECU运行的与位置无关的可运行代码段(例如，如图4所示的代码改变210)。启动代码可以被配置为更新ECU的程序计数器以执行包含在增量文件中的指令，如图4所示。

在一些实施例中，ECU上的软件可以被映射到多个功能单元，并且ECU可以被配置为利用虚拟文件系统(例如，VFS 230，如图5-8所示)来管理和跟踪这些功能单元的一个或多个版本，如图5-8所示。如图5-8所示，启动代码可以被配置为将增量文件链接到与增量文件相关联的VFS中的特定功能。

现在参考图12，示出了示出用于当车辆的ECU正在运行时对ECU软件执行更新的过程1200示例性流程图。根据上述实施例，过程1200可以在图1A所示的系统100中实施。例如，过程1200可以由车辆104-b中的ECU 112执行。

在步骤1202处，当车辆的ECU(例如，车辆104-b的ECU 112)正在运行时，过程1200可以接收用于ECU软件的软件更新文件(例如，增量文件206)。在步骤1204处，当ECU仍在运行时，过程1200可以将软件更新文件写入ECU的存储器(例如，存储器120)中的第一存储器位置(例如，图4中存储增量文件206的存储器位置)，同时执行ECU的存储器中的第二存储器位置(例如，图4中存储当前软件204的存储器位置)中的现有代码的代码段。在步骤1206处，过程1200可以基于软件更新文件，在不中断当前正在执行的ECU的存储器中的第二存储器位置中的代码段的执行的情况下来更新与ECU的存储器相关联的多个存储器地址。

在一些实施例中，如上面所讨论的，用于ECU软件的软件更新文件可以包括具有集成的启动代码的增量文件。过程1200可以例如在将软件更新文件写入ECU的第一存储器位置之前初始化运行时库。在一些实施例中，过程1200可以被配置为在步骤1208处，在完成软件更新时，删除表示由ECU所引用的变量的过时值的数据。此外，过程1200还可以被配置为在步骤1210处，在完成软件更新之后或者独立于软件更新(例如，周期性地或者根据需要)来对ECU的存储器(例如，存储器120)进行碎片整理。

现在参考图13，示出了示出用于调整车辆ECU软件版本的过程1300的示例性流程图。根据上述实施例，过程1300可以在图1A所示的系统100中实施。例如，过程1300可以由车辆104-b中的ECU 112执行。

在步骤1302处，过程1300可以接收将车辆的ECU(例如，车辆104-b的ECU 112)从执行第一版本的ECU软件(例如，图5所示的版本0)调整到执行第二版本的ECU软件(例如，图5所示的版本1)的提示。在步骤1304处，过程1300可以响应于提示并基于对应于第二版本的ECU软件的增量文件(例如，图5所示的增量文件206)，在车辆中的ECU上配置第二版本的ECU软件用于执行。在步骤1306处，过程1300可以响应于提示，进一步在车辆中的ECU上将第一版本的ECU软件配置成为不可执行。

在一些实施例中，第二版本的ECU软件可以在第一版本的ECU软件之后被部署(例如，如图5-7和图9中T1-T3所示)。可选地，第二版本的ECU软件可以在第一版本的ECU软件之前被部署(例如，如图8和图9中T4所示)。

在一些实施例中，ECU上的ECU软件被映射到多个功能单元，并且ECU被配置为利用虚拟文件系统(例如，VFS 230)来管理和跟踪这些功能单元的一个或多个版本。在步骤1306处，过程1300可以更新ECU中对应于由VFS管理的一个或多个功能单元的存储器地址，以使第一版本的ECU软件不可执行。此外，第二版本的ECU软件可以是具有被VFS禁用的一个或多个功能单元的第一版本的ECU软件。

在一些实施例中，过程1300可以在步骤1308处确定ECU的存储器(例如，存储器120)的利用率高于阈值(例如，75％或90％满)。过程1300还可以在步骤1310处标识用于删除的ECU的存储器的特定内容。此外，过程1300可以基于它们对应的创建日期、版本号、文件大小等来标识用于删除的内容。例如，长时间(例如，阈值时间量)未被使用的旧增量文件可能是用于删除的好候选。在一些实施例中，过程1300还可以选择替换ECU的存储器的全部内容。例如，在步骤1312处，替代于保存原始软件加上多年来接收的多个增量文件，过程1300可以决定擦除存储器的全部内容，并用最新的ECU软件的干净副本来替换。过程1300可以继续将上述基于增量文件的更新过程用于将来的更新。

现在参考图14，示出了示出用于标识车辆中的ECU异常的过程1400的示例性流程图。根据上述实施例，过程1400可以在图1A所示的系统100中实施。例如，过程1400可以由车辆中的控制器(例如，车辆104-b中的处理器114)执行。

在步骤1402处，过程1400可以监测表示ECU(例如，ECU 112)的实时处理活动的数据。在步骤1404处，过程1400可以访问与ECU的处理活动相关的历史数据。在一些实施例中，历史数据可以表示ECU的预期处理活动。此外，过程1400可以监测ECU的操作以生成历史数据。

在步骤1406处，过程1400可以将实时处理活动数据与历史数据进行比较，以标识ECU的实时处理活动中的一个或多个异常。在一些实施例中，异常可以对应于由ECU使用的特定存储器位置。此外，异常可以对应于由ECU使用的存储器位置的特定序列。异常可以对应于流入或流出ECU的数据中的至少一个峰值。此外，异常可以对应于由ECU的处理器正在处理的数据中的至少一个峰值。此外，异常可以对应于ECU的功耗中的至少一个异常。

在步骤1408处，当标识出至少一个异常时，过程1400可以对ECU实施控制动作。在一些实施例中，控制动作可以包括发出将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件(例如，将运行在ECU上的ECU软件的版本回滚到ECU软件的先前版本)的提示。控制动作还可以包括发送与ECU相关联的警报。此外，控制动作可以包括阻止从ECU发送的指令。

在一些实施例中，过程1400可以由车辆中的协调器(例如，如上所述的协调器114)来执行。在一些实施例中，协调器可以是与ECU分离的处理单元。协调器可以被配置为对车辆中的多个ECU(例如，ECU 112和ECU 118)执行所述监测、访问、比较和实施。

现在参考图15，示出了示出用于标识车辆中的ECU异常的过程1500的示例性流程图。根据上述实施例，过程1500可以在图1A所示的系统100中实施。例如，过程1500可以由车辆中的控制器(例如，车辆104-b中的处理器114)执行。

在步骤1502处，过程1500可以监测表示ECU(例如，ECU 112)的实时处理活动的数据。在步骤1504处，过程1500可以接收与被认为在功能上与ECU可比的至少一个其它ECU的处理活动相关的可比数据。如前所述，在一些实施例中，可比数据可以包括实时获得的与被认为与ECU(例如，ECU112)可比的其它ECU(例如，ECU 118)的处理活动相关的数据。可比数据可包括先前收集的与被认为与ECU可比的其它ECU的处理活动相关的数据。在一些实施例中，可以基于与运行在ECU上的ECU软件相关联的规则来获得可比数据。此外，可以基于运行在ECU上的ECU软件的已知有效执行序列来获得可比数据。在一些实施例中，可以基于运行在ECU上的ECU软件的已知潜在恶意执行序列来获得可比数据。在一些实施例中，可以基于与ECU上的ECU软件相关联的映射文件来获得可比数据。还可以基于从其它车辆接收的观测数据来获得可比数据。

在步骤1506处，过程1500可以将实时处理活动数据与可比数据进行比较，以标识ECU的实时处理活动中的一个或多个异常。在一些实施例中，异常可以对应于由ECU使用的特定存储器位置。在一些实施例中，异常可以对应于由ECU使用的存储器位置的特定序列。在一些实施例中，异常可以对应于流入或流出ECU的数据中的至少一个峰值。异常可以对应于由ECU的处理器正在处理的数据中的至少一个峰值。异常也可以对应于ECU的功耗中的至少一个异常。

在步骤1508处，当标识出至少一个异常时，过程1500可以对ECU实施控制动作。在一些实施例中，控制动作可以包括发出将ECU从执行第一版本的ECU软件调整到执行第二版本的ECU软件(例如，将运行在ECU上的ECU软件的版本回滚到ECU软件的先前版本)的提示。控制动作还可以包括发送与ECU相关联的警报。此外，控制动作可以包括阻止从ECU发送的指令。

现在参考图16，示出了示出用于适时地更新车辆中的ECU软件的过程1600的示例性流程图。根据上述实施例，过程1600可以在图1A所示的系统100中实施。例如，过程1600可以由车辆中的控制器(例如，车辆104-b中的处理器114)来执行。

在步骤1602处，过程1600可以包括接收指示需要更新运行在ECU(例如，ECU 112)上的软件的无线传输。在步骤1604处，过程1600可以监测车辆的运行状态，以确定车辆是否处于禁止ECU软件更新的第一运行模式。

在步骤1606处，当运行状态被禁止时，过程1600可以延迟ECU软件更新。当车辆处于第一运行模式时，过程1600可以将ECU软件更新存储在位于车辆上的存储器中用于延迟更新。可选地，在一些实施例中，当车辆处于第一运行模式时，过程1600可以丢弃ECU软件更新(过程1600可以在稍后时间请求ECU软件更新)。

在步骤1608处，过程1600可以继续监测车辆的运行状态，以确定车辆是否处于允许ECU软件更新的第二运行模式。过程1600可以根据预先建立的间隔重复监测车辆的运行状态。在一些实施例中，当车辆在预定的安全运行条件下运行时，可以确定车辆处于第二运行模式。在一些实施例中，当车辆处于断电或怠速状态时，可以确定车辆处于第二运行模式。当车辆已经有一段时间无线通信强度高于强度阈值时，可以确定车辆处于第二运行模式。在一些实施例中，当车辆在预选的环境条件下运行时，可以确定车辆处于第二运行模式。在一些实施例中，当车辆具有误码率低于阈值的网络连接时，可以确定车辆处于第二运行模式。

在步骤1610处，当确定车辆处于第二运行模式时，过程1600可以利用延迟的ECU软件更新来启用ECU的更新。如果过程1600将ECU软件更新的副本存储在位于车辆上的存储器中，则过程1600可以从存储器中检索ECU软件更新的副本并继续更新过程。如果过程1600在车辆处于第一运行模式时丢弃了ECU软件更新，则过程116可以向可以提供ECU软件更新的副本的远程服务器发送消息，接收作为回复的ECU软件更新，并且当车辆处于第二运行模式时在ECU上安装ECU软件更新。

在一些实施例中，过程1600可以在步骤1612处确定指示需要更新软件的无线传输是否包括更新具有超驰状态的指示。如果无线传输包括更新具有超驰状态的指示，则在步骤1614处，过程1600可以立即更新ECU软件，而不管车辆是否处于第一运行模式。

现在参考图17，示出了示出用于自动向一个或多个车辆提供更新的过程1700的示例性流程图。根据上述实施例，过程1700可以在图1A所示的系统100中实施。例如，过程1700可以由服务器102执行。

在步骤1702处，过程1700可以从车辆接收ECU活动数据(例如，车辆104-b中的ECU112的活动日期)。在一些实施例中，ECU活动数据可以对应于车辆中ECU的实际操作。

在步骤1704处，过程1700可以基于ECU活动数据确定影响车辆的软件漏洞。在一些实施例中，可以基于接收的ECU活动数据和预期的ECU活动数据之间的偏差来确定软件漏洞。

在步骤1706处，过程1700可以基于所确定的软件漏洞来标识ECU软件更新。在步骤1708处，过程1700可以发送增量文件，该增量文件被配置为用对应于所标识的ECU软件更新的软件更新来更新ECU上的软件。

在一些实施例中，过程1700可以在车辆组上执行。在一些实施例中，车辆组可以包括具有共同ECU类型的第一车辆集合(例如，车辆104-a、104-b和104-c)。在一些实施例中，过程1700可以通过确定影响第一车辆集合的软件漏洞来确定软件漏洞。

在一些实施例中，过程1700可以在步骤1710处确定可能受软件漏洞影响的第二车辆集合。在一些实施例中，过程1700可以在步骤1712处向第一车辆集合和第二车辆集合两者发送增量文件。此外，增量文件可以包括用于在ECU上安装ECU软件更新的安装代理(例如，如前所述的启动代码)。此外，增量文件可以被配置为在多个车辆中重新校准ECU。过程1700还可以包括指示车辆的ECU响应于ECU软件更新而重启。

现在参考图18，示出了向远程监测服务器报告ECU错误的过程1800的示例性流程图。根据上述实施例，过程1800可以在图1A所示的系统100中实施。例如，过程1800可以由车辆的通信网络中的处理器(例如，车辆104-b中的处理器114)或由服务器102来执行。

在步骤1802处，过程1800可以从车辆内的协调器接收数据。协调器可以被配置为电子轮询车辆中的多个ECU(例如，车辆104-b中的ECU 112和118)，并确定它们是否在正确地响应轮询。在一些实施例中，数据可以直接从ECU接收(即，不需要单独的协调器)。此外，如上面所讨论的，协调器可以被配置为对来自ECU的报告的数据执行一个或多个机器学习或人工智能功能，以确定ECU是否在运行属性(例如，CPU处理、存储器内容、存储器访问模式、驾驶员行为属性等)的允许或预期范围内运行。

在步骤1804处，过程1800涉及基于一个或多个运行时属性生成运行数据的统计模型。如上面所讨论的，这可以是ECU的多层模型的第一层的一部分。统计模型可以基于多变量或单变量时间序列分析，并且可以将诸如CPU或存储器使用、被访问的存储器序列、高速缓存内容或访问历史、页面故障等属性作为考虑因素。统计模型还可以基于在离散时间片的存储器足迹处的运行进程的相关性。此外，统计模型可以基于运行在ECU上的软件的频率或执行路径(例如，基于VFS)。此外，统计模型可以基于驾驶员行为属性(例如，突然或轻微制动、加速或转弯、或制动、加速或转弯的频率等)。此外，统计模型可以考虑OBD消息，诸如OBD错误消息。

在步骤1806处，过程1800涉及从被监测的一个或多个ECU接收实时运行时更新。如上面所讨论的，这可以基于推送或拉取功能。来自ECU的数据可以由车辆中的协调器或远程服务器(例如，服务器102)获得。

在步骤1808处，过程1800可以涉及基于接收的数据来标识与ECU相关联的ECU错误。在一些实施例中，通过将统计模型(如上所述)与来自ECU的实时运行时更新进行比较来确定ECU误差。在一些实施例中，收集的数据可以包括ECU的标识符。收集的数据可以包括指示ECU的最后已知轮询的数据。在一些实施例中，过程1800可以基于收集的数据来确定ECU的停机概率。在步骤1808处，过程1800可以基于收集的数据从车辆向远程监测服务器(例如，服务器102)无线地发送报告(标识ECU和标识出的ECU错误)。

在一些实施例中，过程1800可以通过向ECU发送请求消息来轮询ECU，并确定ECU是否在正确地响应轮询。在一些实施例中，过程1800可以基于ECU未能响应轮询来标识ECU错误。过程1800还可以基于ECU错误地响应轮询来标识ECU错误。在一些实施例中，过程1800可以基于ECU中检测到的堆栈上溢来标识ECU错误。

在一些实施例中，过程1800可以轮询ECU以确定ECU是否正在执行对车辆的一个或多个硬件组件具有潜在影响的ECU软件。过程1800可以基于对由车辆的一个或多个硬件组件报告的数据执行的一个或多个统计分析来确定ECU是否正在执行具有潜在影响的ECU软件。

在步骤1810中，过程1800可以进一步涉及从车辆向服务器(例如，服务器102)无线地发送标识已经检测到的ECU和ECU错误的报告。随后，服务器102可以对所标识的ECU和错误执行进一步分析。在一些实施例中，服务器102可以进一步接收从ECU收集的运行时数据的样本、在ECU处运行的增量文件的标识、ECU的软件版本、或ECU存储器的实际内容等。

过程1800还可以在步骤1812处确定潜在影响是否有害。在这种情况下，在步骤1814处，可以对ECU实施控制动作。例如，可以使用上述基于增量文件的软件更新过程来调整ECU。此外，可以指示ECU运行回滚到ECU软件的先前版本或者执行更新到ECU软件的新版本。此外，在一些实施例中，控制动作可以包括将ECU放置于具有有限的特定功能(例如，网络通信、存储器修改等)的安全运行模式。

应当理解，所公开的实施例在它们的应用中不必局限于在以下描述中阐述的和/或在附图和/或示例中示出的组件和/或方法的构造和布置的细节。所公开的实施例能够变化，或者能够以各种方式实践或执行。

所公开的实施例可以在系统、方法和/或计算机程序产品中实施。计算机程序产品可以包括其上具有用于使得处理器执行本公开的各方面的计算机可读程序指令的计算机可读存储介质(或多个介质)。

计算机可读存储介质可以是有形设备，其可以保留和存储指令以供指令执行设备使用。计算机可读存储介质可以是，例如但不限于，电子存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或前述的任何合适的组合。计算机可读存储介质的更具体示例的非穷举列表包括以下内容：便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式光盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备(诸如其上记录有指令的穿孔卡或凹槽中的凸起结构)以及前述的任何适当组合。本文使用的计算机可读存储介质不应被解释为瞬时信号本身，诸如无线电波或其它自由传播的电磁波、通过波导或其它传输介质传播的电磁波(例如，通过光纤电缆的光脉冲)，或者通过电线传输的电信号。

本文描述的计算机可读程序指令可以经由网络(例如互联网、局域网、广域网和/或无线网络)从计算机可读存储介质下载到相应的计算/处理设备，或者下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光传输光纤、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配器卡或网络接口从网络接收计算机可读程序指令，并转发计算机可读程序指令以存储在相应计算/处理设备内的计算机可读存储介质中。

用于执行本公开的操作的计算机可读程序指令可以是汇编指令、指令集架构(Instruction-Set-Architecture，ISA)指令、机器指令、机器相关指令、微码、固件指令、状态设置数据，或者以一种或多种编程语言(包括面向对象的编程语言，诸如Smalltalk、C++等，以及传统的过程编程语言，诸如“C”编程语言或类似的编程语言)的任意组合编写的源代码或目标代码。计算机可读程序指令可以完全在用户的计算机上执行，部分在用户的计算机上执行，作为独立的软件包，部分在用户的计算机上执行并且部分在远程计算机上执行，或者完全在远程计算机或服务器上执行。在后一种场景下，远程计算机可以通过任何类型的网络(包括局域网(LAN)或广域网(WAN)，或者可以到外部计算机的连接(例如，通过使用互联网服务提供商的互联网))连接到用户的计算机。在一些实施例中，包括例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)的电子电路可以通过利用计算机可读程序指令的状态信息来个性化电子电路来执行计算机可读程序指令，以便执行本公开的各方面。

本文参考根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图图示和/或框图来描述本公开的各方面。应当理解，流程图图示和/或框图的每个块，以及流程图图示和/或框图中的块的组合，可以通过计算机可读程序指令来实施。

这些计算机可读程序指令可以被提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器以产生机器，使得经由计算机或其它可编程数据处理装置的处理器执行的指令创建用于实施流程图和/或框图的一个或多个块中指定的功能/动作的装置。这些计算机可读程序指令也可以存储在计算机可读存储介质中，该计算机可读存储介质可以指导计算机、可编程数据处理装置和/或其它设备以特定方式运行，使得其中存储有指令的计算机可读存储介质包括制造品，该制造品包括实施流程图和/或框图的一个或多个块中指定的功能/动作的各方面的指令。

计算机可读程序指令也可以被加载到计算机、其它可编程数据处理装置或其它设备上，以使得一系列操作步骤在计算机、其它可编程装置或其它设备上执行，从而产生计算机实施的过程，使得在计算机、其它可编程装置或其它设备上执行的指令实施流程图和/或框图的一个或多个块中指定的功能/动作。

附图中的流程图和框图图示了根据本公开的各种实施例的系统、方法和计算机程序产品的可能实施方式的架构、功能和操作。在这点上，流程图或框图中的每个块可以表示软件程序、代码段或代码部分，其包括用于实施(多个)指定逻辑功能的一个或多个可执行指令。还应该注意的是，在一些替代实施方式中，在块中标注的功能可能以不同于图中标注的顺序发生。例如，取决于所涉及的功能，连续示出的两个块实际上可以基本上同时执行，或者这些块有时可以以相反的顺序执行。还将注意的是，框图和/或流程图图示的每个块，以及框图和/或流程图图示中的块的组合，可以由执行指定功能或动作的基于专用硬件的系统、或者专用硬件和计算机指令的组合来实施。

出于说明的目的，已经呈现了对本公开的各种实施例的描述，但是这些描述并不旨在穷举或限于所公开的实施例。在不脱离所述实施例的范围和精神的情况下，许多修改和变化对于本领域普通技术人员来说是显而易见的。选择本文使用的术语是为了最好地解释实施例的原理、实际应用或对市场上找到的技术的技术改进，或者使本领域的其它普通技术人员能够理解本文公开的实施例。

预计在从本申请到专利到期期间，将开发许多相关虚拟化平台、虚拟化平台环境、可信云平台资源、基于云的资产、协议、通信网络、安全令牌和认证证书，这些术语的范围旨在先验地包括所有这些新技术。

应当理解，为了清楚起见，在分开的实施例的上下文中描述的本公开的某些特征也可以在单个实施例中组合提供。相反，为了简洁起见，在单个实施例的上下文中描述的本公开的各种特征也可以分开提供，或者以任何合适的子组合提供，或者在本公开的任何其它描述的实施例中合适地提供。在各种实施例的上下文中描述的特定特征不被认为是这些实施例的必要特征，除非没有这些元件该实施例是不起作用的。

尽管已经结合其特定实施例描述了本公开，但是很明显，对于本领域的技术人员来说，许多替换、修改和变化将是显而易见的。因此，旨在包含落入所附权利要求的精神和广泛范围内的所有这些替换、修改和变化。

Claims (24)

1.一种包括指令的非暂时性计算机可读介质，当由至少一个处理器运行时，所述指令使得所述至少一个处理器执行用于生成用于更新车辆中的电子控制单元ECU上的软件的更新包的操作，所述操作包括：

访问要存储在所述车辆中的所述ECU上的软件更新的多个属性；

访问存储在所述车辆中的所述ECU上的当前软件的对应的多个属性；

将所述多个属性与所述对应的多个属性进行比较；

生成表示在所述比较中确定的所述多个属性和所述对应的多个属性之间的差异的增量文件；以及

向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中运行。

2.根据权利要求1所述的非暂时性计算机可读介质，其中，所述启动代码被集成到所述增量文件中。

3.根据权利要求1所述的非暂时性计算机可读介质，其中，所述启动代码在所述增量文件被所述ECU接收之前被安装在所述ECU上。

4.根据权利要求1所述的非暂时性计算机可读介质，其中，所述启动代码被配置为初始化所述增量文件的运行时库。

5.根据权利要求1所述的非暂时性计算机可读介质，其中，所述启动代码被配置为更新所述ECU的程序计数器以运行包含在所述增量文件中的指令。

6.根据权利要求1所述的非暂时性计算机可读介质，其中，所述增量文件包括表示由所述软件更新所引用的变量的值的变量数据。

7.根据权利要求6所述的非暂时性计算机可读介质，其中，所述启动代码被配置为从所述增量文件中提取所述变量数据，并将所述变量数据放置到所述ECU可访问的存储器中。

8.根据权利要求1所述的非暂时性计算机可读介质，其中，所述增量文件包括用于更新所述ECU中的存储器地址的代码。

9.根据权利要求8所述的非暂时性计算机可读介质，其中，所述启动代码被配置为提取用于更新存储器地址的代码并更新所述ECU中的所述存储器地址。

10.根据权利要求1所述的非暂时性计算机可读介质，其中，所述ECU上的软件被映射到多个功能单元，并且所述ECU被配置为利用虚拟文件系统VFS来管理和跟踪所述多个功能单元中的每一个的一个或多个版本。

11.根据权利要求10所述的非暂时性计算机可读介质，其中，要存储在所述ECU上的所述软件更新的所述多个属性包括由所述VFS管理的所述多个功能单元中的至少一个。

12.根据权利要求1所述的非暂时性计算机可读介质，其中，所述指令还包括：

将第一网格应用于所述软件更新；

将第二网格应用于存储在所述ECU上的所述当前软件；以及

基于所述第一网格和所述第二网格的比较来标识所述多个属性和所述对应的多个属性。

13.根据权利要求12所述的非暂时性计算机可读介质，其中，所述第一网格在一个或多个维度上表示所述软件更新，所述一个或多个维度包括以下中的至少一个：

与所述软件更新相关联的二进制数据，

与所述软件更新相关联的源属性，以及

与所述软件更新相关联的映射文件。

14.根据权利要求1所述的非暂时性计算机可读介质，其中，至少部分地基于用于开发所述软件更新的编程语言来标识所述多个属性。

15.根据权利要求1所述的非暂时性计算机可读介质，其中，至少部分地基于所述软件更新的二进制文件分辨率来标识所述多个属性。

16.根据权利要求1所述的非暂时性计算机可读介质，其中，至少部分地基于与所述软件更新相关联的映射文件来标识所述多个属性。

17.根据权利要求1所述的非暂时性计算机可读介质，其中，所述软件更新是单片文件。

18.根据权利要求1所述的非暂时性计算机可读介质，其中，所述软件更新是与其它文件相互依赖的文件。

19.根据权利要求1所述的非暂时性计算机可读介质，其中，所述操作包括，在将所述增量文件提供给所述ECU之前，检查依赖性系统，以确定是否应该基于正被提供给所述ECU的所述增量文件来更新任何相互依赖的ECU。

20.根据权利要求19所述的非暂时性计算机可读介质，其中，所述操作还包括自动向相互依赖的ECU提供额外的增量文件，以在所述相互依赖的ECU上执行软件更新。

21.一种用于生成用于更新车辆中的电子控制单元ECU上的软件的更新包的系统，所述系统包括：

一个或多个处理器；以及

一个或多个存储器，其具有指令，当由所述一个或多个处理器运行时，所述指令使得所述一个或多个处理器执行以下操作：

访问要存储在所述车辆中的所述ECU上的软件更新的多个属性；

访问存储在所述车辆中的所述ECU上的当前软件的对应的多个属性；

将所述多个属性与所述对应的多个属性进行比较；

生成表示在所述比较中确定的所述多个属性和所述对应的多个属性之间的差异的增量文件；以及

向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中运行。

22.根据权利要求21所述的系统，其中，所述启动代码被配置为初始化所述增量文件的运行时库。

23.一种用于生成用于更新车辆中的电子控制单元ECU上的软件的更新包的计算机实施的方法，所述方法包括：

访问要存储在所述车辆中的所述ECU上的软件更新的多个属性；

访问存储在所述车辆中的所述ECU上的当前软件的对应的多个属性；

将所述多个属性与所述对应的多个属性进行比较；

生成表示在所述比较中确定的所述多个属性和所述对应的多个属性之间的差异的增量文件；以及

向所述ECU提供所述增量文件，其中，所述增量文件被配置为由所述ECU中的启动代码处理，所述启动代码使得所述增量文件能够在所述车辆中的所述ECU中运行。

24.根据权利要求23所述的方法，其中，所述启动代码被配置为初始化所述增量文件的运行时库。

Images