CN115765904A - 汽车嵌入式系统计时 - Google Patents

Abstract

本公开涉及汽车嵌入式系统计时，包括旨在改进车辆功能的系统和方法。提供了提供自定义工具的系统和方法，该自定义工具自动生成一组软件代理，该组软件代理允许系统将消息的处理、传输和接收分开，以实现更好的同步。本文的公开内容还提供一种通过将一个客户端指定为服务器并为在该客户端与该服务器之间永久设置的每个其他客户端分配对称密钥来进行密钥配置的简化方法。还提供了预测车辆中的故障的系统和方法。还提供了在系统崩溃的情况下保留数据的系统和方法。还提供了其中车辆的操作系统检测新外围设备的存在并为该新外围设备拉取相关接口文件的系统和方法。此外，本文提供了一种数据同步解决方案，该数据同步解决方案提供优化级别的同步。

Description

汽车嵌入式系统计时

相关申请的交叉引用

本公开要求2021年9月2日提交的美国临时申请号63/240,190的权益，该临时申请全文以引用方式并入本文。

发明内容

本公开涉及旨在改进车辆功能的系统和方法。

典型的车辆包括执行需要同步的功能的系统。在许多这样的系统中，一些任务具有优先级，允许抢占其他任务，从而暂停第一任务以支持另一任务。一些典型的车辆系统还运行数据的端对端检查和解包。在这些任务中，信号数据和端对端结果数据必须同步，以确保端对端结果对应于正确的数据。然而，如果第二任务抢占端对端检查，则数据将无法正确对应。数据不匹配可能导致需要额外周期才能修复的问题，甚至可能导致系统崩溃。因此，需要一种用于确保任务之间同步的系统。根据本公开，提供了提供自定义工具的系统和方法，该自定义工具自动生成一组软件代理，该组软件代理允许系统将消息的处理、传输和接收分开，以实现更好的同步。在一些实施方案中，预先选择的基于文本的描述符文件格式(例如，特殊格式的DBC文件)用于通过每个总线的多个文件片段来描述车辆的网络。描述符文件格式可能需要某种风格的注释或提供所需信息但不会被执行的存根部分。在另一具体实施中，描述符文件格式可能要求以特定顺序并使用特定标记(例如，使用预定义的变量名)提供数据。在一些实施方案中，代码自动生成软件知道文件格式，并且可以添加将编译而不会出现问题或无需额外处理的信号。

一些实施方案包括一种方法，该方法包括：访问包括用于对总线数据进行解码的信息的文件；基于该文件生成多个软件代理，其中该软件代理在被执行时被配置为经由总线接收原始消息，对原始消息进行解包以生成信号值，为原始消息生成安全保护值；以及响应于来自基于受保护存储器位置中的指令执行的应用程序的实例的对信号值的请求，提供对信号值和安全保护值的同步访问。在一些实施方案中，生成多个软件代理包括：生成用于从第一不安全存储器分区执行的第一指令集，其中该第一指令集在被执行时被配置为从总线接收原始消息；生成用于从受保护存储器分区执行的第二指令集，其中该第二指令集在被执行时被配置为对原始消息进行解包以生成信号值，执行验证以便为原始消息生成安全保护值，存储信号值和安全保护值，并将信号值和安全保护值同步传输到应用程序的实例；生成用于从第二不安全存储器分区执行的第三指令集，其中该第三指令集在被执行时被配置为对原始消息进行解包以生成信号值，将信号值传输到应用程序的实例。在一些实施方案中，总线为控制器局域网(CAN)总线。在一些实施方案中，文件为数据库(DBC)文件，其包括用于对来自至少一个传感器的CAN总线数据进行解码的指令。在一些实施方案中，第一不安全存储器分区为质量管理(QM)分区。在一些实施方案中，受保护存储器分区为汽车安全完整性等级(ASIL)分区。在一些实施方案中，生成安全保护值包括生成端对端(E2E)状态。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的指令，该指令在被控制电路执行时致使控制电路：访问包括用于对总线数据进行解码的信息的文件；基于该文件生成多个软件代理，其中该软件代理在被执行时被配置为经由总线接收原始消息，对原始消息进行解包以生成信号值，为原始消息生成安全保护值；以及响应于来自基于受保护存储器位置中的指令执行的应用程序的实例的对信号值的请求，提供对信号值和安全保护值的同步访问。在一些实施方案中，控制电路致使通过以下操作生成多个软件代理：生成用于从第一不安全存储器分区执行的第一指令集，其中该第一指令集在被执行时被配置为从总线接收原始消息；生成用于从受保护存储器分区执行的第二指令集，其中该第二指令集在被执行时被配置为对原始消息进行解包以生成信号值，执行验证以便为原始消息生成安全保护值，存储信号值和安全保护值，并将信号值和安全保护值同步传输到应用程序的实例；生成用于从第二不安全存储器分区执行的第三指令集，其中该第三指令集在被执行时被配置为对原始消息进行解包以生成信号值，将信号值传输到应用程序的实例。在一些实施方案中，总线为控制器局域网(CAN)总线。在一些实施方案中，文件为数据库(DBC)文件，其包括用于对来自至少一个传感器的CAN总线数据进行解码的指令。在一些实施方案中，第一不安全存储器分区为质量管理(QM)分区。在一些实施方案中，受保护存储器分区为汽车安全完整性等级(ASIL)分区。在一些实施方案中，生成安全保护值包括生成端对端(E2E)状态。

一些实施方案包括一种车辆系统，该车辆系统包括：传感器，该传感器连接到至少一个总线；和控制电路，该控制电路被配置为访问包括用于对经由总线从传感器所接收的总线数据进行解码的信息的文件，以及基于该文件生成多个软件代理，其中该软件代理在被执行时被配置为经由总线接收原始消息，对原始消息进行解包以生成信号值，为原始消息生成安全保护值，以及响应于来自基于受保护存储器位置中的指令执行的应用程序的实例的对信号值的请求，提供对信号值和安全保护值的同步访问。在一些实施方案中，控制电路被配置为通过以下操作生成多个软件代理：

生成用于从第一不安全存储器分区执行的第一指令集，其中该第一指令集在被执行时被配置为从总线接收原始消息；生成用于从受保护存储器分区执行的第二指令集，其中该第二指令集在被执行时被配置为对原始消息进行解包以生成信号值，执行验证以便为原始消息生成安全保护值，存储信号值和安全保护值，并将信号值和安全保护值同步传输到应用程序的实例；生成用于从第二不安全存储器分区执行的第三指令集，其中该第三指令集在被执行时被配置为对原始消息进行解包以生成信号值，将信号值传输到应用程序的实例。在一些实施方案中，总线为控制器局域网(CAN)总线。在一些实施方案中，文件为数据库(DBC)文件，其包括用于对来自至少一个传感器的CAN总线数据进行解码的指令。在一些实施方案中，第一不安全存储器分区为质量管理(QM)分区。在一些实施方案中，受保护存储器分区为汽车安全完整性等级(ASIL)分区。

典型的车辆系统包括硬件模块或软件模块，该硬件模块或软件模块可能需要交换一个或多个密码密钥(例如，临时密钥)，以加密在彼此之间发送的消息。现有系统很繁琐，每个模块都需要许多密钥和证书，才能为每个安全事务提供私有密钥或公共密钥。需要一种改进的、简化的密钥设置方法。本文的公开内容通过将一个客户端指定为服务器并为在该客户端与该服务器之间永久设置的每个其他客户端分配对称密钥来提供这样的方法。此对称密钥最大限度地减少了对永久密钥的需求并且可以用于利用临时密钥。在一些实施方案中，在交换期间，一个客户端可以发起与第二客户端的通信。在一些实施方案中，第二客户端然后可以从服务器请求临时密钥，该临时密钥是针对此事务创建的。服务器还可以验证第一客户端确实请求了通信。服务器可以使用临时密钥响应客户端2。在一些实施方案中，客户端1和客户端2现在拥有共享密钥并且可以安全地通信。此方法减少了所需密钥的数量并简化了安全通信。

一些实施方案包括一种用于在车辆内的第一节点和第二节点之间建立安全通信的方法，该方法包括以下步骤：

从车辆的第一节点接收第一消息，该第一消息包括识别车辆的第二节点的信息；响应于接收到该第一消息，使用车辆的处理电路生成加密密钥；向车辆的第一节点传送识别加密密钥的信息；从车辆的第二节点接收第二消息，该第二消息包括识别车辆的第一节点的信息；使用处理电路基于第一消息确定第二消息有效；以及向车辆的第二节点传送识别加密密钥的信息。在一些实施方案中，第一消息还包括由车辆的第一节点生成的随机数。一些实施方案包括将随机数的散列传送到车辆的第一节点。在一些实施方案中，第二消息还包括由第二节点生成的随机数。一些实施方案包括将随机数的散列传送到车辆的第一节点。在一些实施方案中，车辆的第一节点和车辆的第二节点位于车辆中的共享总线上。在一些实施方案中，通过共享总线完成向车辆的第一节点的传送和向车辆的第二节点的传送。

一些实施方案包括一种用于在车辆内的第一节点和第二节点之间建立安全通信的系统，该系统包括：来自车辆的第一节点的第一消息，该第一消息包括识别车辆的第二节点的信息；来自车辆的第二节点的第二消息，该第二消息包括识别车辆的第一节点的信息，其中该第二消息基于第一消息被确定为有效；和加密密钥，其中该加密密钥被识别给第一节点和第二节点。在一些实施方案中，第一消息还包括由车辆的第一节点生成的随机数。一些实施方案包括随机数的散列，其中该散列被传送到车辆的第一节点。在一些实施方案中，第二消息还包括由第二节点生成的随机数。一些实施方案包括随机数的散列，其中该散列被传送到车辆的第一节点。在一些实施方案中，车辆的第一节点和车辆的第二节点位于车辆中的共享总线上。在一些实施方案中，通过共享总线上的通信，将加密密钥识别给第一节点和第二节点。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：从车辆的第一节点接收包括第一消息，该第一消息识别车辆的第二节点的信息；响应于接收到该第一消息，使用车辆的处理电路生成加密密钥；向车辆的第一节点传送识别加密密钥的信息；从车辆的第二节点接收第二消息，该第二消息包括识别车辆的第一节点的信息；

使用处理电路基于第一消息确定第二消息有效；以及向车辆的第二节点传送识别加密密钥的信息。在一些实施方案中，第一消息还包括由车辆的第一节点生成的随机数。一些实施方案包括将随机数的散列传送到车辆的第一节点。在一些实施方案中，第二消息还包括由第二节点生成的随机数。在一些实施方案中，车辆的第一节点和车辆的第二节点位于车辆中的共享总线上。在一些实施方案中，通过共享总线完成向车辆的第一节点的传送和向车辆的第二节点的传送。

在车辆的整个使用寿命中，将遇到失灵。车辆的失灵不仅会造成不便，诸如影响车辆的性能，而且可能会危及车辆的安全性，从而造成危险。它们还可能导致带有另外问题的其他失灵。考虑到这些复杂情况，尽可能快地检测失灵是有利的，以便在产生危险或昂贵的复杂情况之前解决失灵。具体地，需要一种在故障发生之前预测故障的系统。根据本公开，提供了预测车辆中的故障的系统和方法。在一些实施方案中，该系统包括所有车辆都连接到一台服务器的车辆车队。服务器可以从车队中的多个车辆接收关于车辆的量度和条件的数据。服务器还可以分析所接收的量度并确定特定问题发生的频率。服务器可以存储此信息并继续监视车辆。另一车辆可以报告与特定问题类似或具有所示相关性的量度，并且服务器可以向该车辆提供早期失效检测。在一些实施方案中，服务器可以向车辆传输早期警告，敦促维修或其他动作。以这种方式，本公开提供了一种预测失灵并减轻其可能造成的损害的手段。

一些实施方案包括一种用于预测车辆中的故障事件的方法，该方法包括：使用处理电路监视车辆的多个操作参数和车辆的地理位置；使用处理电路，基于使用操作参数的针对一组车辆的相应值和该组车辆的经历相应故障事件的相应地理位置训练的模型来确定操作参数的值和地理位置可能与故障事件相关；以及使用处理电路，致使响应于该确定而执行动作。一些实施方案还包括将车辆的操作参数和地理位置传输到远程服务器，其中确定操作参数的值和地理位置可能与故障事件相关包括从远程服务器接收指示相关性的信息。在一些实施方案中，模型位于远程服务器处。在一些实施方案中，致使执行动作包括致使提供指示故障事件的通知。在一些实施方案中，致使执行动作包括致使更改多个操作参数中的至少一个操作参数以避免发生故障事件。在一些实施方案中，致使执行动作包括致使在远程服务器处执行动作，其中该动作在车辆内执行。在一些实施方案中，基于由该组车辆提供的新数据重复地更新该模型。

一些实施方案包括一种用于预测车辆中的故障事件的系统，该系统包括：车辆的多个操作参数，车辆的地理位置，基于使用操作参数的针对一组车辆的相应值和该组车辆的经历相应故障事件的相应地理位置训练的模型，操作参数的值和地理位置可能与故障事件相关，其中基于响应于该确定而执行的模型和动作，操作参数的值和地理位置被确定为可能与故障事件相关。一些实施方案包括提供指示车辆的操作参数和地理位置与故障事件的相关性的信息。在一些实施方案中，模型位于远程服务器处。一些实施方案包括指示故障事件的通知。在一些实施方案中，动作包括更改多个操作参数中的至少一个操作参数以避免发生故障事件。在一些实施方案中，动作由远程服务器执行，并且其中该动作在车辆内执行。在一些实施方案中，基于由该组车辆提供的新数据重复地更新该模型。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：使用处理电路监视车辆的多个操作参数和车辆的地理位置；使用处理电路，基于使用操作参数的针对一组车辆的相应值和该组车辆的经历相应故障事件的相应地理位置训练的模型来确定操作参数的值和地理位置可能与故障事件相关；以及使用处理电路，致使响应于该确定而执行动作。一些实施方案包括将车辆的操作参数和地理位置传输到远程服务器，其中确定操作参数的值和地理位置可能与故障事件相关包括从远程服务器接收指示相关性的信息。在一些实施方案中，模型位于远程服务器处。在一些实施方案中，致使执行动作包括致使提供指示故障事件的通知。在一些实施方案中，致使执行动作包括致使更改多个操作参数中的至少一个操作参数以避免发生故障事件。在一些实施方案中，致使执行动作包括致使在远程服务器处执行动作，其中该动作在车辆内执行。在一些实施方案中，基于由该组车辆提供的新数据重复地更新该模型。

系统崩溃是车辆系统中的常见问题。例如，系统可能变得无响应。在这些情况下，系统有丢失数据的风险，因为一些信息可能不可复原或不可恢复。数据丢失可能导致功能无法正常运行或无法正确记录信息，这两种情况都可能导致各种问题。因此，需要一种用于保留数据的系统。根据本公开，提供了在系统崩溃的情况下保留数据的系统和方法。在一些实施方案中，该系统包括备用存储器。在一些实施方案中，该系统可以获取系统信息的一个或多个快照并将其保存在备用存储器中。在一些实施方案中，不会在启动之间清除存储器。以这种方式，所公开的系统提供了一种在崩溃的情况下保留数据的手段。

一些实施方案包括一种用于存储关于车辆的信息的方法，该方法包括：由处理电路检测故障事件；以及响应于该检测：由处理电路在发生故障事件时生成关于车辆的信息；由处理电路基于该信息生成完整性数据；致使由处理电路将关于车辆的信息和完整性数据存储在易失性存储器的一部分中，其中该易失性存储器的该部分被配置为在车辆的操作系统的重新启动期间留存所存储的数据；使用处理电路致使重新启动车辆的操作系统；在重新启动之后，使用处理电路基于完整性数据验证存储在易失性存储器中的信息；以及响应于该验证，致使将关于车辆的信息存储在非易失性存储器中。在一些实施方案中，完整性数据包括循环冗余校验(CRC)。在一些实施方案中，易失性存储器包括随机存取存储器(RAM)。在一些实施方案中，易失性存储器的该部分是易失性存储器的为信息和完整性数据保留的专用部分。在一些实施方案中，检测故障事件包括检测系统崩溃。在一些实施方案中，信息包括车辆中软件状态的快照。在一些实施方案中，生成信息、生成完整性数据以及致使存储信息和完整性数据由紧急栈执行，该紧急栈被编程为在故障事件的情况下执行。一些实施方案包括一种用于存储关于车辆的信息的系统，该系统包括：车辆的操作系统；故障事件；在故障事件发生时关于车辆的信息；基于在故障事件发生时关于车辆的信息生成的完整性数据；易失性存储器的一部分，该部分被配置为在车辆的操作系统的重新启动期间留存所存储的数据，其中关于车辆的信息和完整性数据响应于故障事件而存储在易失性存储器的该部分中；

非易失性存储器，其中响应于重新启动车辆的操作系统，基于完整性数据验证关于车辆的信息，并且其中响应于该验证，关于车辆的信息被存储在非易失性存储器中。在一些实施方案中，完整性数据包括循环冗余校验(CRC)。在一些实施方案中，易失性存储器包括随机存取存储器(RAM)。在一些实施方案中，易失性存储器的该部分是易失性存储器的为信息和完整性数据保留的专用部分。在一些实施方案中，检测故障事件包括检测系统崩溃。在一些实施方案中，信息包括车辆中软件状态的快照。一些实施方案包括紧急栈，该紧急栈被编程为生成信息，生成完整性数据，并且在故障事件的情况下致使存储信息和完整性数据。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：由处理电路检测故障事件；以及响应于该检测：由处理电路在发生故障事件时生成关于车辆的信息；由处理电路基于该信息生成完整性数据；致使由处理电路将关于车辆的信息和完整性数据存储在易失性存储器的一部分中，其中该易失性存储器的该部分被配置为在车辆的操作系统的重新启动期间留存所存储的数据；使用处理电路致使重新启动车辆的操作系统；在重新启动之后，使用处理电路基于完整性数据验证存储在易失性存储器中的信息；以及响应于该验证，致使将关于车辆的信息存储在非易失性存储器中。在一些实施方案中，完整性数据包括循环冗余校验(CRC)。在一些实施方案中，易失性存储器包括随机存取存储器(RAM)。在一些实施方案中，易失性存储器的该部分是易失性存储器的为信息和完整性数据保留的专用部分。在一些实施方案中，检测故障事件包括检测系统崩溃。在一些实施方案中，信息包括车辆中软件状态的快照。

典型的车辆包括外围零件，诸如泵制动器。许多制造商提供多种型号的外围零件。通常，接口文件专用于处理来自特定外围设备的特定文件。如果外围硬件更改，则现有接口文件无法与新的外围设备通信，并且需要全新的接口硬件。这很繁琐，并且可能会在系统中造成延迟。然而，许多外围设备，无论硬件如何，都共享公共部件。因此，提供一种无论外围硬件如何都一致的系统是有利的。具体地，需要一种在不同硬件间使用相同应用程序代码的系统。根据本公开，提供了一种其中车辆的操作系统检测新外围设备的存在并为该新外围设备拉取相关接口文件的系统。在一些实施方案中，该系统在外围文件和接收外围数据的应用程序之间提供抽象层。在一些实施方案中，所有与外围设备相关的软件都可能能够直接或间接地依赖于抽象层，该抽象层可以转换来自任何具有公共功能的外围设备的数据。因此，现在可以更改外围设备而无需替换现有软件。

一些实施方案包括一种用于在安装新硬件部件时更新车辆的方法，该方法包括：使用车辆中的处理电路检测新硬件部件；使用处理电路识别由新硬件部件生成的数据与车辆的至少一个软件部件之间的关联；以及使用处理电路生成用于解译来自硬件部件的数据的更新的接口，其中更新的接口将由硬件部件提供的数据转换为抽象信息，并且其中更新的接口将抽象信息提供给车辆的至少一个软件部件。在一些实施方案中，由新硬件部件生成的数据包括数据库(DBC)文件。一些实施方案包括将更新的接口存储在接口库中，其中生成更新的接口包括从库中访问更新的接口。在一些实施方案中，基于新硬件部件的识别从库中选择更新的接口。一些实施方案包括由车辆的至少一个软件部件处理抽象信息，而无需考虑由新硬件部件生成的数据。在一些实施方案中，更新的接口用于至少一个软件部件和新硬件部件之间的双向通信。在一些实施方案中，生成更新的接口包括修改现有接口。

一些实施方案包括一种用于在安装新硬件部件时更新车辆的系统，该系统包括：新硬件部件；由新硬件部件生成的数据与车辆的至少一个软件部件之间的关联；和接口，该接口被配置为将来自硬件部件的数据转换为抽象信息，其中该接口将抽象信息提供给车辆的至少一个软件部件。在一些实施方案中，由新硬件部件生成的数据包括数据库(DBC)文件。一些实施方案包括接口库，其中存储更新的接口。一些实施方案包括新硬件部件的识别，其中基于新硬件部件的识别从库中选择更新的接口。在一些实施方案中，由车辆的至少一个软件部件处理抽象信息，而无需考虑由新硬件部件生成的数据。在一些实施方案中，更新的接口用于至少一个软件部件和新硬件部件之间的双向通信。在一些实施方案中，更新的接口是对现有接口的修改。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：使用车辆中的处理电路检测新硬件部件；使用处理电路识别由新硬件部件生成的数据与车辆的至少一个软件部件之间的关联；以及使用处理电路生成用于解译来自硬件部件的数据的更新的接口，其中更新的接口将由硬件部件提供的数据转换为抽象信息，并且其中更新的接口将抽象信息提供给车辆的至少一个软件部件。在一些实施方案中，由新硬件部件生成的数据包括数据库(DBC)文件。一些实施方案包括致使处理器将更新的接口存储在接口库中，其中生成更新的接口包括从库中访问更新的接口。在一些实施方案中，基于新硬件部件的识别从库中选择更新的接口。一些实施方案包括致使处理器由车辆的至少一个软件部件处理抽象信息，而无需考虑由新硬件部件生成的数据。在一些实施方案中，更新的接口用于至少一个软件部件和新硬件部件之间的双向通信。

车辆管理系统的关键部件包括定期数据传送。有时，同一总线上的多个节点必须具有传送数据的能力。此外，对于车辆功能而言，这些传送中的一些传送必须同步。虽然一些节点可能以基本同步或松散同步运行，但其他节点需要非常精确的同步。然而，精确的同步依赖于在客户端和服务器之间来回的许多消息，并且精确地同步每个节点可能会使系统不堪重负，从而使总线饱和并降低性能。需要一种能够同时适应松散同步和紧密同步的混合解决方案。如本公开中所描述，本文提供了一种混合解决方案，该混合解决方案提供了在需要时提供紧密同步而在不需要紧密同步时提供松散同步的优点。如所公开，系统的服务器可以连续传输其内部时间。然后，接收节点可以将其从服务器接收到消息的时间与服务器的内部时间进行比较，并计算差值。然后，节点可以调整其内部时间以使其匹配服务器的内部时间，从而实现松散同步。对于紧密同步，节点可以请求精确同步并且可以在请求中包括其自己的时间戳。服务器可以用接收到请求的时间(这反映了服务器和客户端之间的任何延迟)以及它的响应时间来响应。节点可以计算服务器接收和服务器传输之间的延迟，以及节点传输和节点接收之间的延迟，并减去这些值。节点还可以通过创建节点时钟和服务器时钟之间的时间差的平均值来计算时钟偏移。可以由节点使用偏移值来修改其本地时钟以使其与服务器时钟紧密匹配(例如，通过将往返延迟和时钟偏移添加到其内部时钟)。

另外，在一些具体实施中，节点可以存储所计算的时钟偏移和往返延迟的历史。如果历史指示稳定模式，则节点可以降低其请求紧密同步的频率或停止发送对紧密同步的请求，并且可以依赖历史值来执行同步。有利地，如果两个节点彼此同步，则它们可以使用来自服务器的相同消息来执行服务器紧密同步，因为它们的传输值将相同。

一些实施方案包括一种用于在第一客户端、第二客户端和时间服务器(该第一客户端、该第二客户端和该时间服务器各自与相应本地时钟相关联)之间进行紧密同步的系统，该系统包括：时间服务器，该时间服务器连接到总线；第一客户端，该第一客户端连接到总线；第二客户端，该第二客户端连接到总线，其中第一客户端被配置为通过在总线上传输同步消息来请求与时间服务器的紧密同步，其中时间服务器被配置为生成在总线上传送的周期性同步消息，

时间服务器客户端被配置为基于来自第一客户端的紧密同步请求来调整周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，该第一时间指示第一客户端何时传输同步消息；(b)第二时间，该第二时间指示服务器何时接收紧密同步请求；和(c)第三时间，该第三时间指示时间服务器何时发送周期性同步消息，第一客户端被配置为基于经调整的周期性同步消息来执行紧密同步，并且第二客户端被配置为基于经调整的周期性同步消息来执行松散同步。在一些实施方案中，第一客户端还被配置为基于经调整的周期性同步消息的内容和经调整的周期性同步消息的接收时间来执行紧密同步。在一些实施方案中，同步消息包括指示第一时间的数据。一些实施方案包括用于存储关于时间服务器和第一客户端之间的延迟的信息的存储器。一些实施方案包括基于延迟确定模式并基于该模式致使在第一客户端和时间服务器之间发生同步的电路。

一些实施方案包括一种用于在第一客户端、第二客户端和时间服务器(该第一客户端、该第二客户端和该时间服务器各自与相应本地时钟相关联并且各自连接到总线)之间进行紧密同步的方法，该方法包括：由时间服务器生成要通过总线传送的周期性同步消息；在时间服务器处通过总线接收同步消息，该同步消息包括来自第一客户端的对紧密同步的请求；响应接收到该同步消息，由时间服务器基于紧密同步请求来调整周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，该第一时间指示第一客户端何时传输同步消息；(b)第二时间，该第二时间指示服务器何时接收紧密同步请求；和(c)第三时间，该第三时间指示时间服务器何时发送周期性同步消息；由第一客户端基于经调整的周期性同步消息来执行紧密同步；以及由第二客户端基于经调整的周期性同步消息来执行松散同步。一些实施方案包括基于经调整的周期性同步消息的内容和经调整的周期性同步消息的接收时间来执行紧密同步。在一些实施方案中，第一客户端、第二客户端和时间服务器位于车辆上。在一些实施方案中，同步消息包括指示第一时间的数据。一些实施方案包括将关于时间服务器和第一客户端之间的延迟的信息存储在存储器中。一些实施方案包括由处理电路基于延迟确定模式并基于该模式致使在第一客户端和时间服务器之间发生同步。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：由时间服务器生成要通过总线传送的周期性同步消息；在时间服务器处通过总线接收同步消息，该同步消息包括来自第一客户端的对紧密同步的请求；响应接收到该同步消息，由时间服务器基于紧密同步请求来调整周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，该第一时间指示第一客户端何时传输同步消息；(b)第二时间，该第二时间指示服务器何时接收紧密同步请求；和(c)第三时间，该第三时间指示时间服务器何时发送周期性同步消息；由第一客户端基于经调整的周期性同步消息来执行紧密同步；以及由第二客户端基于经调整的周期性同步消息来执行松散同步。一些实施方案包括致使处理器基于经调整的周期性同步消息的内容和经调整的周期性同步消息的接收时间来执行紧密同步。在一些实施方案中，第一客户端、第二客户端和时间服务器位于车辆上。在一些实施方案中，同步消息包括指示第一时间的数据。一些实施方案包括致使处理器将关于时间服务器和第一客户端之间的延迟的信息存储在存储器中。一些实施方案还包括致使处理器基于延迟确定模式并基于该模式致使在第一客户端和时间服务器之间发生同步。

单元测试是任何软件系统(包括操作车辆部件的软件系统)的整体部分。在典型的车辆系统中，软件功能可以使用从第二函数所接收的输入。为了确保结果，有利地是，使用提供这些值的第二函数的模拟版本，利用来自第二函数的每个可能输入来测试第一函数。然而，许多函数都是以编程语言编写的，在这种语言中，提供函数的模拟版本需要单独的函数。然后，单独的函数需要在测试环境中进行繁琐的替换。需要一种将模拟函数集成到主函数中的解决方案，以用于以独立于模拟函数的语言编写的函数。根据本文的公开内容，提供了一种解决方案，该解决方案将所有函数分别编译成汇编代码，该汇编代码被缝合在一起成为一个超级图像。在缝合期间，对每个子图像进行调整，以适应它们现在位于不同地址空间的事实。将待编译图像馈送到大型图像创建程序(MICP)中。对于每个图像，MICP定位该图像在存储器中的位置，使其不与其他图像的存储器要求冲突。然后，对于每个图像，MICP调整其中的机器指令以反映新的最终地址位置。接下来，作为最终大型图像创建的一部分，MICP创建进入大型图像内的每个子图像以及单元测试框架的入口点表，该大型图像是所有子图像的组合。然后，可以将单个文件闪存到可以用于测试和生产的驱动器上。以这种方式，在函数中提供模拟函数进行测试，而不管使用的编程语言如何。

一些实施方案可以包括一种用于函数重载的方法，该方法包括：编译函数的第一版本的第一图像；编译函数的第二版本的第二图像；以及通过将定义函数的第一版本的代码和定义函数的第二版本的代码放置到存储器分区中来生成缝合的超级图像，其中定义函数的第二版本的代码被调整为与函数的第一版本的代码不冲突，并且生成表，该表用于选择性地调用函数的第一版本和函数的第二版本中的任一者。在一些实施方案中，函数的第一版本和函数的第二版本以不允许函数重载的代码编写。在一些实施方案中，函数的第一版本和函数的第二版本以C代码编写。在一些实施方案中，存储器分区位于车辆内。在一些实施方案中，该表为函数的第一版本和函数的第二版本中的每一者定义相应的存储器地址。在一些实施方案中，函数的第一版本的第一图像包括第一汇编代码，而函数的第二版本的第二图像包括第二汇编代码。一些实施方案还包括基于该表调用缝合的超级图像中的函数的每个版本。

一些实施方案包括一种函数重载系统，该系统包括：

存储器分区，该存储器分区包括定义函数的第一版本的代码和定义函数的第二版本的代码，其中定义函数的第二版本的代码被调整为与函数的第一版本的代码不冲突；表，该表被配置为选择性地调用函数的第一版本和函数的第二版本中的任一者；和缝合的超级图像，该缝合的超级图像由表和存储器分区生成。在一些实施方案中，函数的第一版本和函数的第二版本以不允许函数重载的代码编写。在一些实施方案中，函数的第一版本和函数的第二版本以C代码编写。在一些实施方案中，存储器分区位于车辆内。在一些实施方案中，该表为函数的第一版本和函数的第二版本中的每一者定义相应的存储器地址。在一些实施方案中，函数的第一版本的第一图像包括第一汇编代码，而函数的第二版本的第二图像包括第二汇编代码。在一些实施方案中，基于该表调用缝合的超级图像中的函数的每个版本。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：编译函数的第一版本的第一图像；编译函数的第二版本的第二图像；以及通过将定义函数的第一版本的代码和定义函数的第二版本的代码放置到存储器分区中来生成缝合的超级图像，其中定义函数的第二版本的代码被调整为与函数的第一版本的代码不冲突，并且生成表，该表用于选择性地调用函数的第一版本和函数的第二版本中的任一者。在一些实施方案中，函数的第一版本和函数的第二版本以不允许函数重载的代码编写。在一些实施方案中，函数的第一版本和函数的第二版本以C代码编写。在一些实施方案中，其中存储器分区位于车辆内。在一些实施方案中，该表为函数的第一版本和函数的第二版本中的每一者定义相应的存储器地址。在一些实施方案中，函数的第一版本的第一图像包括第一汇编代码，而函数的第二版本的第二图像包括第二汇编代码。一些实施方案还包括致使处理器基于该表调用缝合的超级图像中的函数的每个版本。

附图说明

通过结合附图考虑以下具体实施方式，本公开的上述和其他目的和优点将显而易见，其中类似的参考字符始终指代类似的部分，并且其中：

图1示出根据本公开的一些实施方案的车辆的部件的框图，

图2示出根据本公开的一些实施方案的用于操作车辆(例如，来自图1)的系统的框图，

图3示出根据本公开的一些实施方案的图1的车辆的示例性架构，

图4a示出根据本公开的一些实施方案的引起同步问题的抢占的示例性发生，

图4b示出根据本公开的一些实施方案的生成的软件代理的示例性数据流图，

图5示出根据本公开的一些实施方案的由代码自动生成软件的构建系统创建的示例性软件代理，

图6示出根据本公开的一些实施方案的由代码自动生成软件的构建系统创建的示例性软件代理的替换版本，

图7示出根据本公开的一些实施方案的图5中描述的信号接收检查的示例性具体实施的细节，

图8示出根据本公开的一些实施方案的图5中描述的传输过程的示例性具体实施的细节，

图8a示出根据本公开的一些实施方案的用于同步数据的方法的例示性步骤的流程图，

图9示出根据本公开的一些实施方案的示例性密钥交换场景，

图10示出根据本公开的一些实施方案的基于对称密钥的改进的密钥设置协议，

图11示出根据本公开的一些实施方案的加密算法中的节点的状态机，

图12示出根据本公开的一些实施方案的加密算法中的密钥服务器的状态机，

图12a示出根据本公开的一些实施方案的用于在车辆内的第一节点和第二节点之间建立安全通信的方法的例示性步骤的流程图，

图13示出根据本公开的一些实施方案的用于改进车辆的电路或部件中的失效检测的示例性系统，

图13a示出根据本公开的一些实施方案的用于预测车辆中的故障事件的方法的例示性步骤的流程图，

图14示出根据本公开的一些实施方案的用于促进崩溃恢复的示例性系统，

图14a示出根据本公开的一些实施方案的用于存储关于车辆的信息的方法的例示性步骤的流程图，

图15示出根据本公开的一些实施方案的用于管理微控制器的数据库文件的版本的示例性系统，该微控制器诸如图1至图3中的任一图中描绘的车辆的微控制器，

图15a示出根据本公开的一些实施方案的用于在安装新硬件部件时更新车辆的方法的例示性步骤的流程图，

图16示出根据本公开的一些实施方案的用于管理经由单个总线连接的不同模块的时间同步的示例性系统，

图17示出根据本公开的一些实施方案的需要紧密同步的节点与服务器之间的交互，

图18示出根据本公开的一些实施方案的示出往返行程延迟的示例性交互，

图18a示出根据本公开的一些实施方案的用于在第一客户端、第二客户端和时间服务器之间进行紧密同步的方法的例示性步骤的流程图，

图19示出根据本公开的一些实施方案的用于测试第一单元的第二单元的示例性代码，

图20示出根据本公开的一些实施方案的正在测试的所使用的第一单元的示例性代码，

图21示出根据本公开的一些实施方案的创建图19和图20的代码的超级图像的示例性结果，

图21a示出根据本公开的一些实施方案的用于函数重载的方法的例示性步骤的流程图。

具体实施方式

车辆概况

根据本公开，提供了通过对车辆、多个车辆和/或配置为与一个或多个车辆通信的一个或多个服务器的硬件和/或软件的配置进行各种改进来改进车辆(或多个车辆)的操作的系统和方法。

图1示出根据本公开的一些实施方案的车辆100的部件的框图。在一些实施方案中，车辆100可以包括用于控制和操作车辆的多种合适系统中的任一种。例如，车辆100可以包括一个或多个发动机系统、电池系统、自主驱动系统、一个或多个转向系统、泵制动系统、通风系统以及其他合适的系统或其任何组合。在一些实施方案中，车辆可以包括用于控制上述系统中的一些或全部的一个或多个电子控制单元(ECU)或电路(例如，微控制器)。在一些实施方案中，车辆可以包括链接车辆的系统所需的内部连接或网络部件。

在一些实施方案中，车辆可以包括一个或多个处理器105(例如，中央处理器和/或专用于其子系统的处理器)。处理器可以包括用于执行存储在存储器103或软件模块112、113或其组合中的命令的硬件CPU。在一些实施方案中，车辆100可以包括一个或多个瞬态存储器单元和/或一个或多个非晶体管存储器单元。在一些实施方案中，存储器103可以为车辆电路的一部分。在一些实施方案中，存储器103可以包括用于非暂态存储命令或指令的硬件元件，在被处理器105执行时，所述命令或指令致使处理器105根据上文和下文所述的实施方案来操作车辆100。

在一些实施方案中，处理器105可以通信地连接到传感器106、107、联网部件和一个或多个用户接口部件。传感器106、107可以包括视频传感器、音频传感器、气体传感器、压力传感器、GPS传感器、无线电天线、摄像机、麦克风、压力传感器、重量传感器、气体传感器、特定于车辆能力的传感器、其他传感器或其任何组合。

在一些实施方案中，处理器105可以使用来自传感器106、107的数据来操作车辆100和/或执行其他功能。在一些实施方案中，处理器105可以经由用户界面102接收用户输入。在一些实施方案中，用户界面102可以包括屏幕。在一些实施方案中，处理器105可以经由网络与用户设备和其他数据源通信，该网络可以经由联网部件104访问。

在一些实施方案中，车辆100可以包括多个软件模块(例如，软件模块1-N)112、113。在一些实施方案中，软件模块1-N 112、113中的每个软件模块可以由处理器105控制。在一些实施方案中，车辆100可以包括多个硬件模块(例如，硬件模块1-N)114、115。在一些实施方案中，硬件模块1-N 114、115中的每个硬件模块可以由处理器105控制或由其自己的处理器操作。在一些实施方案中，车辆100可以包括特定于车辆100的操作功能的电路和软件。例如，车辆100可以包括用于控制车辆100的一个或多个电机的电控模块(ECM)或电控单元(ECU)111中的一者或多者。每个ECM 111可以访问各种传感器，例如：MAP：歧管绝对压力、IAT：进气温度、MAF：气流质量、CKP：曲轴位置、CMP：凸轮轴位置、ECT：发动机冷却剂温度、O2：氧传感器、TP：节气门位置、VSS：车速传感器、爆震传感器、APP：加速踏板位置、制冷剂传感器、任何其他合适的传感器或其任何组合。车辆100可以包括用于车辆的一个或多个变速器的变速器控制模块(TCM)108、车辆动力学模块(VDM)109和中央网关模块(CGM)110。车辆还可以包括任何其他合适的硬件或软件系统。

联网概述

图2示出根据本公开的一些实施方案的用于操作车辆(例如，来自图1)的系统的框图。该系统可以包括多个车辆，包括车辆210(例如，图1的车辆)和其他车辆220和230，以及服务器250。

在一些实施方案中，该系统可以包括将车辆210、220、230和服务器250通信地互连的网络240。在一些实施方案中，网络240可以为互联网、内联网、蓝牙网络、LAN、WAN、Wi-Fi网络、任何其他有线或无线网络或其任何组合。

在一些实施方案中，每个车辆210-230可以包括用于执行如本公开的各种实施方案中所描述的车辆的功能的处理电路。在一些实施方案中，车辆210-230中的每个车辆可以包括用于存储车辆操作所需的数据和指令的瞬态和非瞬态存储器。在一些实施方案中，车辆210-230中的每个车辆可以包括用于通过网络240与服务器250通信的通信电路。在一些实施方案中，车辆210-230中的每个车辆的处理电路可能能够从传感器或者硬件模块或软件模块(例如，如图1所示)收集数据。车辆210-230可以为消费者车辆，或者在一些实施方案中表示商用车辆车队。

在一些实施方案中，服务器250可以包括单个服务器。在一些实施方案中，服务器250可以包括分布在一个或多个设施中的多个服务器。在一些实施方案中，服务器250可以经由网络240从车辆210-230收集信息(例如，由车辆210-230的传感器生成的信息)。在一些实施方案中，服务器250可以根据以上和以下描述的实施方案经由网络240向车辆210-230发送信息。

核心架构概述

图3描绘图1的车辆的示例性架构(例如，车辆的处理器核心中的一个处理器核心，例如ECM的核心)。例如，图3所示的架构可以使用图1所示的处理器和存储器来实现。虽然示出单个核心的具体实施，但是车辆可以包括由总线或联网元件连接的任何数量的核心。

在一些实施方案中，该按机构可以使用微控制器301来实现。微控制器301可以访问硬件抽象模块307、操作系统内核302(具有核心间通信功能)和自检库303。另外的安全和保密模块可以包括端对端(E2E)保护模块304、监视模块305和冗余模块306。这些模块中的一些或全部可以使用共享存储器。核心还可以执行专用于执行间隔任务的部分。

在一些实施方案中，该架构包括控制器抽象层308，该控制器抽象层可以访问控制器局域网(CAN)309、串行外围接口(SPI)310、集成电路总线(l2C)311、通用异步收发器(UART)312、本地互联网络(LIN)313和数字输入/输出(DIO)314总线。微控制器301还可以包括芯片组驱动器315、引导加载程序316、控制器局域网先进先出(FIFO)队列317和以太网部件318。还可以包括另外的联网模块(例如，包括用于FreeRTOS通信320的网关319、统一数据系统(UDS)通信321、通用测量和校准协议(XCP)通信322、互联网协议诊断(DoIp)通信323、ISO传输层(ISOTP)通信324、VX1000通信325等)。微控制器301还可以包括ECU外围驱动器326、硬件抽象模块307和诊断事件管理器327。然后，内核302可以用于执行存储在存储器中的应用程序代码。在一些实施方案中，核心的架构可以包括任何其他合适的硬件或软件模块。

核心使得车辆能够访问各种功能和能力，包括通信、同步和数据收集。例如，车辆可以通过DoIP 323在外部测试装备与汽车控制单元(ECU)(使用ECU外围驱动器326)之间传送信息(诸如诊断或故障代码)。例如，这允许车辆系统跟踪和分析诊断信息，以改进失效检测。核心还可以经由控制器局域网(CAN)总线或统一诊断服务(UDS)协议接收文件并将文件发送到外部系统(诸如云服务器)。例如，这些文件可能来自外围设备(例如，来自泵制动器模块、来自发动机模块(诸如ECM)或任何其他核心或者车辆的外围设备或传感器的信号)，或去往其他模块、其自身应用程序或其他核心。该通信实现了合并来自车辆的不同部分(即，与显示单元通信的制动器，或存储ECU失效后的数据快照)或来自不同系统(即，向外部服务器报告数据)的数据的功能。

在一些实施方案中，车辆(例如，如图1所描绘)的系统(例如，如图3所示的核心)可能能够从外部模块(例如，从传感器、车辆的其他模块(诸如TCM或VDM))接收消息和信号。DBC文件可以用于定义模块之间的通信方式(例如，泵制动模块、发动机模块(诸如ECM)或车辆的任何其他核心、外围设备或传感器)。车辆的系统(例如，如图3所示的核心300)可能还需要传输数据(例如，将数据传输到其他模块，传输到其自身的应用程序，或传输到其他系统的其他核心)。

在一种方法中，系统包括用于接收和解译数据的单独编程接口，和/或用于传输数据的应用程序。在一些实施方案中，系统可以在实时操作系统(RTOS)中执行。在RTOS中，任务具有优先级，并且允许相互抢占。由于抢占，一个任务可能会暂停其执行，此时执行另一个具有更高优先级的任务。抢占可能导致数据的一致性失效。

图4A示出导致同步问题的抢占的示例性发生。例如，Task0_5ms和Task0_100ms都可以被调度为在系统(例如，核心)上以t＝0ms运行。由于task0_5ms具有较高优先级，因此允许首先执行，并因此在时间t＝0ms开始执行。当task0_5ms结束时(例如，在t＝2ms时)，允许在核心上执行task0_100ms(例如，在t＝2ms时)，但task0_100ms可能没有足够的时间，直到需要再次运行对task0_5ms的第二次调用(在t＝5ms时)。系统的操作系统将“抢占”task0_100ms，以支持更高优先级的任务task0_5ms，并运行任务task0_5ms的第二实例直到完成(例如，直到t＝7ms)，然后切换回以完成task0_100ms任务(例如，t＝7ms)。有问题的是，此抢占无法保证task0_5ms和task0_100ms之间的通信将同步。

例如，task0_5ms可以负责信号数据(例如，经由CAN总线所接收的数据)的端对端(E2E)检查和解包。在该示例中，task0_100ms可能需要接收：(a)信号数据；和(b)该信号的E2E检查结果(将由task0_5ms提供)。例如，task0_100ms可以在其执行的2ms-5ms部分期间调用一个函数来获取信号数据，然后在其执行的7ms-8ms部分调用不同的函数来获取E2E状态。然而，由于task0_5ms的第二实例是在5ms-7ms时间段之间执行的，因此task0_100ms在7ms-8ms时间段内所接收的E2E状态将不会与task0_100ms在2ms-5ms时间段内所接收的信号数据相对应。如果task0_100ms在与task0_5ms不同的核心上运行，则此问题会变得更加严重。数据不匹配可能导致在task0_100ms的执行过程中出现不同步等编程问题，这可能需要额外的周期来补救，甚至可能导致系统崩溃。

此问题的先前解决方案将在执行需要数据的应用程序代码所在的同一分区中执行E2E计算。这提供了E2E和消息数据与代码的同步，因为所有信息在相同的上下文中运行，然而这些此类解决方案具有缺点。一方面，需要在通信栈的上下文和上述上下文之间同步消息数据。这通常通过涉及操作系统或可移植性和资源密集度较低的队列来处理。此外，如果有代码在其他分区运行，则需要进行冗余计算。这些解决方案还要求代码与传入的数据同步运行。

因此，提供了一种确保任务之间同步的解决方案，例如提供了一种确保E2E数据与信号处理和发送数据同步的方法。具体地，提供了自定义工具(例如，一组编程脚本)，该自定义工具自动生成一组软件代理(例如，以C编程语言)，该组软件代理允许系统(例如，包括一个或多个核心)将消息的处理、传输和接收分开，以实现更好的同步。具体地，用于接收信号的E2E计算可以在单个任务内发生，而核心和应用程序(将接收或发送信号和E2E状态)的软件架构执行必要的动作，以确保在需要时同步接收信息。这可以节省核心上的CPU周期(例如，图3所示的核心300)

图4B示出生成的软件代理的示例性数据流程图。在一些实施方案中，车辆中的每个应用程序(例如，如图1至图3所示)需要接收和发送数千个信号。此外，有些消息需要通过许多网络路由到车辆系统中的各个端点。一些消息需要验证(例如，使用E2E状态)。用于处理消息接收和用于E2E验证的人工生成代码容易出错，并且可能会将错误合并到系统中。因此，本文的系统基于DBC数据自动生成代码，其中所得代码使得自定义的软件代理能够提供信号和E2E状态同步。例如，可以为以下任务自动生成代码：网络之间的消息的网关；原始字节和工程值之间的信号的解包/打包；对于消息/信号完整性的端对端保护的处理；消息调度的处理；通信网络的变体管理；通信相关的DTC(诊断故障代码)的设置；通过网络/消息对通信的启用/禁用；以及任何其他合适的通信相关任务。

在一些具体实施中，预先选择的基于文本的描述符文件格式(例如，特殊格式的DBC文件或其他序列化格式)用于通过每个总线的多个文件片段来描述车辆的网络。例如，描述符文件格式可能需要某种风格的注释或提供所需信息但不会被执行的存根部分。在另一具体实施中，描述符文件格式可能要求以特定顺序并使用特定标记(例如，使用预定义的变量名)提供数据。DBC文件或任何其他合适的预先选择的描述符文件格式可以由使用描述符文件格式详细信息的代码自动生成软件使用。代码自动生成软件可以使用这些描述符文件的段或片段来生成源代码。以这种方式，可以传输信号或消息，并保证代码将编译，并且内核和应用程序将能够通过指定应用程序编程接口(API)访问消息或信号的值，而无需进行任何进一步的工作或集成。代码自动生成软件还可以处理变体管理(例如，如稍后结合图15所描述)。在一些实施方案中，代码自动生成软件可以包括用于提供自动消息冗余的框架(例如，当有多个消息源可供选择时，通过临时方式切换消息源)。在一些实施方案中，代码自动生成软件可以包括用于替换DBC文件的新文件格式的模式。

代码自动生成软件的输出可以是旨在在核心(例如，ECU的核心)的应用程序栈的顶层上运行和/或与应用程序一起运行的一组编程文件。生成的由一种或多种编程语言(例如，C、C++、Javascript等)组成的编程文件可以负责处理数据(例如，通过生成包含实际可用值的文件)，负责对信号数据执行E2E验证，以及负责将信号数据发送到其他核心或应用程序。E2E检查模块可以被配置为在给定过去消息的运行状态的情况下验证单个消息。E2E库可以根据汽车开放系统架构(AUTOSAR)规范来编写。E2E检查可以提供验证信号消息所需的“错误”、“正常”、“重复”、“无新数据”或“错误序列”值中的一者。

在一些示例中，代码自动生成软件的构建系统可以接收源DBC文件(例如，以包括公共部分和变体的片段形式)。然后，构建系统可以使用网络成帧器聚合器来执行变体处理和执行DBC反序列化。构建系统可以使用预定义的网络对象(例如，通过每个总线的多个文件片段来描述网络)和所提供的模板来生成运行时环境对象(例如，下面在图5至图8中更详细地描述的软件代理)。构建系统还可以创建聚合的DBC文件。

所得软件代理可以提供存储器保护和安全执行环境。例如，从外围设备所接收的所有数据都需要在安全环境中执行。另外，存储器保护需要处于活动状态，以保护执行关键任务所需的存储器(例如，需要禁止任何不合格的进程访问受保护的存储器)。为此，存储器(例如，如图1所示)可以分为若干部分(例如，按照ISO 26262标准来定义)：QM存储器部分，该QM存储器部分可以为不受保护的不合格级别的存储器；和各种级别的ASIL部分(例如，ASIL A-D)，其中每个级别的ASIL存储器都受到更多保护。代码自动生成软件生成在图5至图8中进一步解释的代码。

图5示出由代码自动生成软件的构建系统创建的示例性软件代理，这些软件代理在被一起执行时，自动为接收信号提供E2E保护处理。

具体地，上部矩形中的任务由核心1执行(例如，在核心1的应用程序栈的顶层上)。而较低级别的任务由依赖于该信号的较高级别应用程序任务执行。如上文在图4A中所解释的，应用程序任务需要与E2E保护任务同步(以避免应用程序接收到对应于错误消息的E2E状态)。为此，当接收到消息(例如，从核心0)时，该消息由核心1上的E2E任务502读取(例如，使用E2E库503)。然后，核心1上的E2E任务502以应用程序可以使用的形式写入信号和信号的E2E状态两者。然后，E2E状态可以由使用ASIL B 504或ASIL D 505存储器保护级别的软件读取，而信号本身可以由使用ASIL B 504、ASIL D 505或QM 506保护级别的软件访问。有利地，每个E2E消息的所有跨核心通信(例如，作为E2E检查)都发生在核心1处，这允许支持更高级别的存储器保护(例如，在ASIL D级别)。由于E2E计算全部发生在一个任务内，因此应用程序还将执行必要的动作以确保在需要时同步所接收的信息。

图6示出由代码自动生成软件的构建系统创建的示例性软件代理的另一版本，这些软件代理在被一起执行时，自动为接收信号提供E2E保护处理。与图5的具体实施相反，E2E检查由应用程序处理。例如，E2E计算可以在与消耗计算但要求任务以与消息相同的速率运行的代码相同的上下文中执行。

具体地，上层607中的任务601由核心1执行(例如，在核心1的应用程序栈的顶层上)。而下层608中的任务由依赖于该信号的较高级别应用程序任务执行。为此，当接收到消息(例如，从核心0)时，由核心1读取该消息，核心1写入消息以供应用程序使用。在该具体实施中，使用ASIL B 602、ASIL D 603或QM 604级别或保护的软件都可以访问消息。然后，使用ASIL B 602的软件和使用ASIL D 603的软件都可以访问E2E库605并生成E2E消息(例如，作为E2E检查)。在此类实施方案中，应用程序可以在每个消息周期期间执行E2E检查。

图7示出图5中描述的信号接收检查的示例性具体实施的细节。虚线字段表示由代码自动生成软件的构建系统创建的代码。如图所示，不同的代码代理可以驻留在ASIL B701、ASIL D 702和QM 703分区中，并且可以一起执行以确保app任务和Com任务(其可以对应于图4A中描述的任务)之间的同步。在这种情况下，运行Com任务的QM分区中的代码经由FIFO 704缓冲区接收消息，并以ASIL B 701、ASIL D 702和QM 703分区中的代码可以访问的格式写入信号或消息。ASIL B分区701中的代码可以对消息进行解包并写入信号数据以及E2E状态。然后，应用程序可以以同步的方式访问这两个值。ASIL D 702分区中的代码类似地可以对消息进行解包并写入信号数据以及E2E状态。然后，应用程序可以以同步的方式访问这两个值。此外，ASIL D 702中的代码可以执行安全任务。QM分区703中的代码可能仅使信号数据可用于应用程序，而不是E2E数据。

图8示出图5中描述的传输过程的示例性具体实施的细节。虚线字段表示由代码自动生成软件的构建系统创建的代码。如图所示，不同的代码代理可以驻留在ASIL B 801、ASIL D 802和QM 803分区中，并且可以一起执行以确保app任务和Com任务(其可以对应于图4A中描述的任务)之间的同步。在这种情况下，运行Com任务的QM分区803中的代码基于ASIL B 801、ASIL D 802和QM 803分区中的代码提供的信号将消息写入FIFO缓冲区804。ASIL B分区801中的代码可以通过组合信号数据和E2E状态来打包消息。ASIL B分区801中的代码还可以通过组合信号数据和E2E状态来打包消息。此外，ASIL D 802中的代码可以执行安全任务。QM分区中的代码只能向Com任务发送信号数据(而不是E2E状态)。

一些实施方案包括如图8a所示的方法，该方法包括：在步骤810中，访问包括用于对总线数据进行解码的信息的文件；在步骤820中，基于该文件生成多个软件代理，其中该软件代理在被执行时被配置为经由总线接收原始消息，对原始消息进行解包以生成信号值，为原始消息生成安全保护值；以及如果在步骤830中接收到来自基于受保护存储器位置中的指令执行的应用程序的实例的对信号值的请求，则在步骤840中提供对信号值和安全保护值的同步访问。如果在步骤830处未接收到请求，则该方法移动到步骤850并且不采取任何动作。在一些实施方案中，生成多个软件代理包括：生成用于从第一不安全存储器分区执行的第一指令集，其中该第一指令集在被执行时被配置为从总线接收原始消息；生成用于从受保护存储器分区执行的第二指令集，其中该第二指令集在被执行时被配置为对原始消息进行解包以生成信号值，执行验证以便为原始消息生成安全保护值，存储信号值和安全保护值，并将信号值和安全保护值同步传输到应用程序的实例；生成用于从第二不安全存储器分区执行的第三指令集，其中该第三指令集在被执行时被配置为对原始消息进行解包以生成信号值，将信号值传输到应用程序的实例。在一些实施方案中，总线为控制器局域网(CAN)总线。在一些实施方案中，第一不安全存储器分区为质量管理(QM)分区。在一些实施方案中，受保护存储器分区为汽车安全完整性等级(ASIL)分区。在一些实施方案中，生成安全保护值包括生成端对端(E2E)状态。

在一些实施方案中，不同的硬件模块或软件模块可能需要交换一个或多个密码密钥(例如，临时密钥)，以加密在彼此之间发送的消息。例如，车辆的TCM、VDM和CGM(例如，如图1至图3所示)可能需要在每对模块之间建立安全通信信道。然而，在需要交换密钥的任何软件或硬件模块之间可以使用相同的技术。

在一种方法中，每个模块或节点可以具有其自己的私有密钥/公共密钥对以用于安全通信。然而，这可能会很麻烦，尤其是当需要证书来验证密钥源时。为了克服此缺点，提供了用于改进的密钥设置过程的示例性方法。

图9描绘示例性现有技术密钥交换场景。在此示例中，4个节点创建成对对称通信密钥(例如，DEC密钥，尽管可以使用任何其他合适的密钥)。如上所述，成对密钥生成通常需要6次密钥交换，这很繁琐。例如，对于20个节点，需要190个密钥对。为了克服这些现有方法的问题，提供了一种基于利用一个节点和服务器之间的预共享密钥来在节点之间生成临时对称密钥的方案。将针对任何两个节点和一个服务器来描述该技术。在一些示例中，CGM可以充当服务器，并且TCM、VDM可以为节点。然而，可以使用任何其他合适的服务器和任何其他合适的节点。在一些实施方案中，可以对需要共享所设置的密钥的其他节点重复该过程。

图10描绘了基于对称密钥的改进的密钥设置协议，该协议可以用于在运行时(或在任何其他时间)在多个节点之间设置新的对称密钥。该解决方案允许仅使用先前对称密钥来安全设置新的对称密钥。该技术可防止窃听和中间人攻击。为了部署该解决方案，可以将网络中的一个节点指定为密钥服务器，而将其余节点指定为密钥客户端。作为第一步，每个客户端都在其自身和服务器之间永久设置对称密钥。这最大限度地减少了对永久密钥的需求。例如，对于20个节点，只需要20个密钥，而不是190个密钥对。预共享密钥允许节点与服务器节点通信，并且还可以被利用来创建临时密钥以用于加密节点之间的通信。

如图10所示，客户端1希望通过共享临时对称密钥来创建与客户端2的安全信道。客户端1从密钥服务器请求对称密钥(例如，新创建的临时密钥)1001。在一些实施方案中，该请求包括用于信道创建的目标节点的地址(例如，客户端2的IP地址)和客户端1生成的随机数(例如，16位数)。随机数可以用作服务器的质询问题。例如，当使用密钥答复时，可以期望服务器基于该数字重新传输答复，以通过检查所接收的质询响应来帮助客户端1验证服务器。此消息可以在不加密的情况下发送，也可以使用客户端1/服务器的预共享密钥来加密。

在某个预设时间段期满之前，服务器可以使用包括新设置的密钥和对质询的响应的消息来答复客户端1 1002。可以使用任何合适的密钥创建技术(例如，如IEEE Std 1363-2000标准中所定义)来创建新设置的密钥。对询问的响应可以是客户端1发送的随机数的散列(例如，基于密码的消息认证码散列)。也可以填充该消息以使其符合加密块大小。可以使用为客户端1/服务器对预共享的密钥(例如，使用密码)来对整个消息进行加密。在一些实施方案中，客户端1创建的随机数可以用作加密算法的初始化向量。

然后，客户端1可以检查散列，然后再继续进行。在散列检查之后，客户端1可以向客户端2发送消息，以通知客户端2客户端1希望发起与客户端2的安全通信1003。这可能是未加密的(例如，用户数据报协议(UDP))消息。该消息可以通知客户端2(例如，经由位字段)信道是否需要加密、认证或两者兼有。客户端2现在获悉服务器已经为此事务生成了临时密钥。客户端2现在可以向服务器发送消息，以请求为其自身复制新设置的临时密钥1004。

客户端2现在可以向服务器发送对临时密钥的请求1004。该请求可以包括期望节点的地址(例如，客户端1的IP地址)和客户端2生成的随机数(例如，16位数)。此消息可以在不加密的情况下发送，也可以使用客户端2/服务器的预共享密钥来加密。

服务器可以验证在响应客户端2之前，客户端1确实先前已请求了与客户端2的信道。对客户端2的响应消息1005可以包括：(a)对随机数质询的响应(例如，客户端2生成的随机数的散列)；和(b)在客户端1的请求下设置的相同密钥。也可以填充该消息以使其符合加密块大小。可以使用为客户端2服务器对预共享的密钥(例如，使用密码)来对整个消息进行加密。在一些实施方案中，客户端2创建的随机数可以用作加密算法的初始化向量。

客户端2可以检查响应散列，然后再继续进行1006。此后，由于客户端1和客户端2拥有相同的密钥，因此它们可以利用该密钥来进行安全通信(例如，用于在彼此之间签名或加密消息)。在一些实施方案中，可以通过正常UDP或传输控制协议(TCP)消息或任何其他合适的消息来执行通信。

图11示出该算法中节点的状态机1100。例如，从“空闲”状态1101开始，节点可以发送密钥请求1102(例如，发送到TCM)，并等待重试预定次数。在发起方模式下，当接收到密钥答复时1103(并且如果认证未失败)，节点可以向对等方查询安全连接1104。如果接收到对等方答复，则状态返回到“空闲”1101，并且可以开始与对等方的通信。在接收模式下，节点将回复对等方以指示允许相同的通信1105。

图12示出了该算法中密钥服务器的状态机。从“空闲”状态1201开始，服务器可以接收发起请求1202。作为响应，服务器发送答复1203或超时1204，并返回到“空闲”状态1201。

一些实施方案包括一种用于在车辆内的第一节点和第二节点之间建立安全通信的方法(如图12a所示)，该方法包括以下步骤：

从车辆的第一节点接收包括第一消息，该第一消息识别车辆的第二节点的信息1210；响应于接收到该第一消息，使用车辆的处理电路生成加密密钥1220；向车辆的第一节点传送识别加密密钥的信息1230；从车辆的第二节点接收第二消息，该第二消息包括识别车辆的第一节点的信息1240；使用处理电路基于第一消息确定第二消息有效1250；以及向车辆的第二节点传送识别加密密钥1260的信息。在一些实施方案中，第一消息还包括由车辆的第一节点生成的随机数。一些实施方案包括将随机数的散列传送到车辆的第一节点。在一些实施方案中，第二消息还包括由第二节点生成的随机数。一些实施方案包括将随机数的散列传送到车辆的第一节点。在一些实施方案中，车辆的第一节点和车辆的第二节点位于车辆中的共享总线上。在一些实施方案中，通过共享总线完成向车辆的第一节点的传送和向车辆的第二节点的传送。

图13描绘了用于改进车辆(例如，图1中描绘的车辆)的电路或部件中的失效检测的示例性系统。例如，失效检测可以由服务器1300(例如，如图2中描绘)执行。在一些实施方案中，服务器可以访问来自商业车队环境内的多个车辆1301、1302、1303、1304的量度数据，或者车辆1301、1302、1303、1304可以表示与和车辆制造商相关联的服务器通信的一组消费者车辆。例如，服务器可以使用服务器和车队的联网电路(例如，通过蜂窝网络或任何其他合适类型的网络)与车队中的每个车辆持续或定期通信。服务器可以从车队中的车辆的所有线路收集数据1305。在一个示例中，服务器可以收集车队中所有车辆的ECU量度数据。

在服务器从一组车辆收集ECU量度之后，服务器可以将量度数据存储在其数据库中。服务器可以将量度与阈值进行对比分析，并确定整个车队中某个问题(例如，故障)发生的频率，以及该故障与量度的相关性。通过跟踪此信息，服务器可能能够提供车辆中的早期失效检测。在一些实施方案中，服务器可以向车辆传输早期警告1306，该早期警告指示故障并敦促维修或另一适当动作。

例如，服务器可以为每个车辆的每个ECU收集传感器数据，以记录电机负载、电池状态或充电、冷却剂温度、电机温度、电机RPM、空气流量、任何其他合适的量度或其任何组合。进一步复杂的ECU量度可以包括当前和平均处理器负载、任何处理器故障、RAM和非易失性存储器利用率(平均和当前)、ECU核心温度(当前和平均)、网络负载(平均和当前)、可用时间历史、任何其他合适的处理器量度或其任何组合。服务器还可以收集电机的任何元件的健康信息，例如可以收集电机的任何零件的年龄和性能。服务器还可以从车队中的每个车辆接收软件崩溃或故障报告。服务器可以将崩溃的发生与崩溃时或崩溃前车辆的状态和量度历史相关联。随着从其他车辆接收到更多崩溃或失灵报告，这种相关性可能会变得更强。例如，某个电机零件的老化或不良性能可能与即将发生的故障相关。在一些实施方案中，车辆可以向服务器报告信息，以便既分析相关性的发现，又接收相关性本身的故障警告。也就是说，车辆既可以为系统知识做出贡献，又可以从系统本身中受益。当服务器确定相关性(例如，相关性超过某个阈值)时，服务器可以将即将发生的故障警告传输到零件状况与故障相关的车辆。在一些实施方案中，可以基于任何量度或量度组合与特定故障的相关性来发送警告。警告可以包括关于车辆的哪个部分需要维修或更换的通知。服务器可以类似地为车辆的任何其他模块收集和生成数据。

在一些实施方案中，服务器可以利用机器学习模型(例如，神经网络)来预测故障。在此类实施方案中，服务器用已知导致故障的量度状态来训练机器学习模型。一旦经过训练，机器学习模型就可以接受车辆的当前量度(例如，ECU量度)作为输入，并输出是否可能发生即将发生的故障。如果可能出现故障，则服务器可以向车辆发送适当的通知。在一些实施方案中，随着服务器收集新数据，模型被重复更新。在一些实施方案中，模型位于远程服务器处。

在一些实施方案中，对车辆的通知可以指示预期故障。在一些实施方案中，通知可以指示预期故障可能发生的范围。此范围可以以英里、小时或任何其他相关单位为单位。例如，服务器可以基于检测到的电池或电机部件的状态来警告车辆在20英里内可能会过热。在另一示例中，服务器可以基于与车辆相关联的灯或其他电路的识别状态来警告车辆前灯可能在12小时内熄灭。在一些实施方案中，通知可以描述相关性。例如，这可以表明车辆已行驶65,000英里，这表明电机很可能需要维护。

在一些实施方案中，通知可以包括将发生故障的百分比可能性。例如，服务器可能警告车辆有40％的电池失效几率。在一些实施方案中，该通知可以包括严重程度的指示，诸如驾驶员可以看到的车辆显示器上的颜色变化或动画，或者该指示可以被传递到与用户相关联的移动设备(例如，其上安装有与服务器相关联的移动应用程序的移动电话)。例如，紧急风险可能会显示为红色并闪烁，而轻微风险可能会显示为黄色。严重程度可以例如基于可能性和潜在危险或不便来评估。在一些实施方案中，服务器可以致使更改车辆的操作参数，以避免或减轻故障。这种更改可以由远程服务器使用软件或其他更新以无线方式对车辆执行。

在一些实施方案中，服务器可以从车辆以外的源接收数据。例如，服务器可以与提供天气、交通模式、车辆地理位置、海拔、路线和驾驶员配置文件等数据的系统通信。然后，服务器可以将此附加数据合并到故障相关性分析中。例如，服务器可能会发现某个故障(诸如电池性能)与外部温度相关。然后，在接收到未来几个小时的天气预报后，服务器可能会警告车辆可能会发生故障。例如，在电池性能与温度相关的情况下，服务器可以了解到温度可能下降到阈值以下，此时温度将损害电池性能。然后，服务器可以警告车辆即将发生的变化或即将发生的性能受损的可能性。另选地，服务器可以发现例如另一故障在频繁停车时很常见，并且可以接收到关于即将到来的交通的信息。服务器可以了解到前方交通可能导致频繁停车。在那种情况下，服务器可以类似地警告车辆可能发生失效。在另一示例中，服务器可能会发现某个地理位置的车辆与特定故障的相关性较高，并仅向该位置的车辆发出特定故障的警告。在一些实施方案中，服务器可以建议某一动作。例如，在交通模式可能增加失效风险的场景中，服务器可能会向系统传达推荐替代路线。

一些实施方案包括一种用于预测车辆中的故障事件的方法(如图13a所示)，该方法包括在步骤1310中，使用处理电路来监视车辆的多个操作参数和车辆的地理位置。在步骤1320中使用处理电路确定操作参数的值和地理位置可能与故障事件相关时，其中该相关性基于使用操作参数针对一组车辆的值和该组车辆的经历相应故障事件的相应地理位置训练的模型，在步骤1330中使用处理电路致使响应于该确定而执行动作。如果未检测到相关性，则该方法移动到步骤1340并且不采取任何动作。一些实施方案还包括将车辆的操作参数和地理位置传输到远程服务器，其中确定操作参数的值和地理位置可能与故障事件相关包括从远程服务器接收指示相关性的信息。在一些实施方案中，模型位于远程服务器处。在一些实施方案中，致使执行动作包括致使提供指示故障事件的通知。在一些实施方案中，致使执行动作包括致使更改多个操作参数中的至少一个操作参数以避免发生故障事件。在一些实施方案中，致使执行动作包括致使在远程服务器处执行动作，其中该动作在车辆内执行。在一些实施方案中，基于由该组车辆提供的新数据重复地更新该模型。

图14描绘了用于通过车辆系统(例如，如图1所示)促进崩溃恢复(例如，ECU的崩溃)的示例性系统。例如，系统可以处理当ECU锁定并变得无响应时的情况，因此系统可以防止在不可恢复的陷阱或另一模块重置整个核心(例如，如图3所示)之后数据丢失。在这些情况下，系统避免了硬动力循环，而是遭受“软”或“热”崩溃。因此，可以留存易失性存储器内容。

如图14所示，车辆的示例性系统可以包括具有处理器1401的核心、常规随机存取存储器(RAM)存储器1402(在图14中标记为“主存储器”)和专用备用RAM存储器1403(在图14中标记为“备用存储器”)。在一些实施方案中，备用RAM存储器可以为常规RAM存储器的一部分。在一些实施方案中，备用RAM存储器可以为专用电路。车辆的操作系统(OS)可以包括专用于低级别故障(例如，低级别ECU失效)、坏代码或存储器保护失效或看门狗触发事件的指令。处理器可以获取系统信息的快照并将其保存在备用RAM存储器中。为此，系统可以在链接器结构中保留RAM的一部分，该部分在启动之间不会被清除。

在一些实施方案中，处理器可以通过为在崩溃之后获取并存储在备用RAM 1403中的快照块计算循环冗余校验(CRC)代码1404来保护数据。这样，在重新启动之后，可以执行CRC校验1404以检查数据是否有效。然后可以经由控制器局域网(CAN)总线或统一诊断服务(UDS)协议来报告数据。系统还可以在备用存储器中设置“新”标志以指示新数据的存在。备用RAM中的崩溃数据稍后可以被复制到非易失性存储器和/或外部系统(例如，另一核心或微控制器)。

在一些实施方案中，非易失性存储器(NVM)可以用于存储快照。这样，包含崩溃信息的缓冲区不会在后续启动时被擦除，而是被复制到非易失性存储器中。例如，核心可以包括用于在锁定状态下执行额外功能的紧急栈。在崩溃期间，系统可以设置指向紧急栈的指针，并调用新函数来获取快照。在一些实施方案中，看门狗模块中的栈溢出可以被重定向到不可屏蔽的中断处理程序。

在一些实施方案中，快照可以包括栈追踪。例如，系统可以访问20深的预分配无符号整数列表，每个整数都保存一个跳回指令地址。在一些实施方案中，快照可以包括软件git散列。在一些实施方案中，快照可以包括陷阱标识符。在一些实施方案中，快照可以包括看门狗状态。在一些实施方案中，快照可以包括自由运行系统定时器值。在一些实施方案中，快照可以包括任何感兴趣的数据(栈指针、状态寄存器、时间戳等)。

在一些实施方案中，当引导加载程序启动时，可以通过心跳帧将崩溃数据快照转储到CAN总线。然后，引导加载程序可以正常操作。在一些实施方案中，数据转储可以由附接到总线(例如，附接到CAN总线)的数据记录器记录。

在一些实施方案中，快照可以是可以使用UD客户端经由诸如统一诊断服务(UDS)协议的服务获得的打包二进制文件。二进制文件可以包括具有定义函数的头文件。然后，可以使用python工具将数据解包为人类或系统可读的格式。在一些实施方案中，系统可以在正常操作期间获取快照(例如，周期性地或基于系统或用户请求)，以提供添加的管理工具。在一些实施方案中，可以从整个车队收集快照数据，并用于预测其他车辆中的失效，例如，如图13所述。

一些实施方案包括一种用于存储关于车辆的信息的方法(如图14a所示)，该方法包括：由处理电路检测故障事件1410；以及响应于该检测：由处理电路在发生故障事件时生成关于车辆的信息1420；由处理电路基于该信息生成完整性数据1430；致使由处理电路将关于车辆的信息和完整性数据存储在易失性存储器的一部分中，其中该易失性存储器的该部分被配置为在车辆的操作系统的重新启动期间留存所存储的数据1440；使用处理电路致使重新启动车辆的操作系统1450；在重新启动之后，使用处理电路基于完整性数据验证存储在易失性存储器中的信息1460；以及响应于该验证，致使将关于车辆的信息存储在非易失性存储器中1480。在一些实施方案中，完整性数据包括循环冗余校验(CRC)。在一些实施方案中，易失性存储器包括随机存取存储器(RAM)。在一些实施方案中，易失性存储器的该部分是易失性存储器的为信息和完整性数据保留的专用部分。在一些实施方案中，检测故障事件包括检测系统崩溃。在一些实施方案中，信息包括车辆中软件状态的快照。在一些实施方案中，生成信息、生成完整性数据以及致使存储信息和完整性数据由紧急栈执行，该紧急栈被编程为在故障事件的情况下执行。

一些实施方案包括一种用于存储关于车辆的信息的系统，该系统包括：车辆的操作系统；故障事件；在故障事件发生时关于车辆的信息；基于在故障事件发生时关于车辆的信息生成的完整性数据；易失性存储器的一部分，该部分被配置为在车辆的操作系统的重新启动期间留存所存储的数据，其中关于车辆的信息和完整性数据响应于故障事件而存储在易失性存储器的该部分中；

非易失性存储器，其中响应于重新启动车辆的操作系统，基于完整性数据验证关于车辆的信息，并且其中响应于该验证，关于车辆的信息被存储在非易失性存储器中。在一些实施方案中，完整性数据包括循环冗余校验(CRC)。在一些实施方案中，易失性存储器包括随机存取存储器(RAM)。在一些实施方案中，易失性存储器的该部分是易失性存储器的为信息和完整性数据保留的专用部分。在一些实施方案中，检测故障事件包括检测系统崩溃。在一些实施方案中，信息包括车辆中软件状态的快照。一些实施方案包括紧急栈，该紧急栈被编程为生成信息，生成完整性数据，并且在故障事件的情况下致使存储信息和完整性数据。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：由处理电路检测故障事件；以及响应于该检测：由处理电路在发生故障事件时生成关于车辆的信息；由处理电路基于该信息生成完整性数据；致使由处理电路将关于车辆的信息和完整性数据存储在易失性存储器的一部分中，其中该易失性存储器的该部分被配置为在车辆的操作系统的重新启动期间留存所存储的数据；使用处理电路致使重新启动车辆的操作系统；在重新启动之后，使用处理电路基于完整性数据验证存储在易失性存储器中的信息；以及响应于该验证，致使将关于车辆的信息存储在非易失性存储器中。在一些实施方案中，完整性数据包括循环冗余校验(CRC)。在一些实施方案中，易失性存储器包括随机存取存储器(RAM)。在一些实施方案中，易失性存储器的该部分是易失性存储器的为信息和完整性数据保留的专用部分。在一些实施方案中，检测故障事件包括检测系统崩溃。在一些实施方案中，信息包括车辆中软件状态的快照。

图15描绘了用于管理微控制器(例如，图1至图3中的任一图中描绘的车辆的微控制器)的数据库(DBC)文件的版本的示例性系统。DBC文件可以是符合SAE J1939标准的定义文件。DBC文件也可以是特殊格式的定义文件，如图4至图8所述。DBC文件可以用于通过控制器局域网(CAN)总线从外围设备(例如，从泵制动器模块、发动机模块(诸如ECM)或车辆的任何其他外围设备或传感器)提供数据。DBC通常采用必须解译的形式。例如，来自DBC的数据可能以表1所示的格式显示：

0

18FE6900

X

8

9C 27DC 29FF FF F3 23

49.745760

R

表1

该数据可以被解码以接收某些定义的参数的值。例如，从泵制动系统所接收的DBC文件可以定义俯角值。在另一示例中，从发动机系统所接收的DBC文件可以定义包括歧管温度、电机每分钟转数的值。从二进制DBC数据到可用值的转换可由通过CAN或以太网总线接受数据的接口文件来执行。

在一种方法中，单个接口文件专用于处理来自某个外围设备(例如，来自泵制动器模块)的某个DBC文件。然而，如果要使用不同的泵制动器对泵制动器硬件进行物理修改，则这需要完全替换接口文件以处理新版本的外围设备。这种方法无法利用外围设备的不同版本的DBC文件之间的共性，因此无法使用仍然可以使用的接口文件的共同部分，而是需要全新的接口文件，这可能导致在获取和安装新接口文件时出现繁重的延迟。此外，接口文件中的更改还可能需要整个系统的更改，这些更改依赖于来自DBC文件解译器的数据。因此，单个外围设备的更改可能需要在车辆(或另一系统)的整个架构上进行更改。

为了克服上述方法的问题，提供了一种车辆架构的具体实施，其在整个系统的板上保持应用程序代码相同，同时根据车辆类型、车辆架构或基于特定外围设备的替换提供不同的接口。例如，不同版本的车辆可能需要不同的接口。在另一示例中，更换外围设备可能导致需要新版本的DBC解译器接口。在一个示例中，车辆可以接收例如需要新接口文件的新泵制动器硬件。

在一些实施方案中，车辆的操作系统可以通过检测构建配置事件来检测新外围设备(例如，新泵制动器)的存在。然后，操作系统可以拉入新的接口文件以闪存到车辆的硬件中。例如，操作系统可以识别源文件和车辆软件部件之间的关联(例如，来自新泵制动器的数据和处理泵制动器输入的应用程序和/或使用来自泵制动器的数据操作的任何应用程序之间的关联)。然后，操作系统可以在根目录中组合相关联的源文件，并基于组合的源文件为车辆软件部件(例如，可能需要泵制动器数据的ECU)生成至少一个接口抽象层。

例如，泵制动器模块可以提供DBC文件，该DBC文件为制动踏板提供俯角值。然而，由于不同的制动器具有不同的“让步”，因此车辆的其他部分(例如，ECU或TCM)可能以完全不同的方式处理制动器俯角值的相同角度变化。为了解决该问题，系统可以在通过相关联接口进行的DBC解译和为系统中的其他模块执行的应用程序之间提供抽象层1506。例如，抽象层可以向系统提供“预期速度变化”值，而不是原始角度值。例如，对于一种类型的泵制动器，5度的变化表示期望降低5MPH，而对于另一种类型的泵制动器，5度的变化表示期望降低7MPH。如果与制动动作相关的所有软件都被编程为依赖于期望的速度变化量度，则可以提供抽象层，该抽象层将来自泵制动器的DBC数据转换为期望的速度变化量度，然后再将该数据提供给其他应用程序。这样，可以轻松更改泵制动器的接口版本，而无需对系统的其余部分进行任何其他更改。类似的抽象可以用于DBC文件提供的任何其他值。因此，可以在不考虑新硬件部件生成的数据的情况下处理抽象信息。

接口版本的更新可以由图15所示的系统执行。例如，车辆可以包括统一诊断服务(UDS)服务器1501，该服务器允许外部设备执行UDS操作(例如，设置运行时控制，检索运行时控制和擦除运行时控制)。这些操作可能受CRC保护。UDS服务器使得可以将被称为UDS客户端的计算机1502(例如，计算机或专用测试器工具)连接到车辆(例如，经由UDS接口)。UDS客户端1502可以(例如，经由诸如互联网的外部网络)使用车辆的编码运行时配置文件进行设置。编码的运行时配置文件1503可以被发送到UDS服务器1501，该UDS服务器然后可以将其写入车辆的存储器中的变体库1504。车辆可以使用非易失性存储器，并且任选地使用一个或多个附加库(诸如掉电恢复应用程序)来解码运行时配置文件1503。结果，可以将附加的解码运行时配置1505添加到变体库存储器。然后，应用程序(例如，ECM应用程序)可以在运行时间期间从库中请求所需的配置。任选地，可以存在可供应用程序使用的抽象层，该抽象层可以访问抽象的数据而不是来自DBC文件的原始值。

在一些实施方案中，代替离散版本，变体库可以定义不同版本的运行时指令中的不同之处。例如，代码的某些部分可能会在代码中混淆，以实现不同的版本。在一些具体实施中，构建系统可以访问车辆生成信息，并使用该信息来识别硬件差异。例如，可以访问电池或HVAC的不同接口ID。相反，如果使用特定于某一车辆型号的配置，系统可能会识别车辆的哪些部分不同。例如，如果两个车辆具有不同的HVAC系统，则可以在配置中切换用于控制HVAC的软件模块，而不会影响配置的其余部分(这可以通过使用抽象来实现)。可以使用新的本地互连网络(LIN)表来实现此功能。在另一实施方案中，调度表可用于在运行时切换到。例如，可以将相同的二进制文件加载到所有车辆，并且系统可以在运行中选择正确的代码并忽略与其他配置相关的代码。

在一些实施方案中，可以用运行时配置选项代替构建时配置选项。例如，以这种方式，对于所有的车辆变体，可以仅使用单个二进制。此变体库可以设置所有其他配置选项。还可以使用变体库来存储车辆的用户可配置或可选择的变体选项。作为另一示例，可选择的变体可以由车辆上的车轮尺寸来定义。由于车轮尺寸对车辆动力学有影响，因此车轮尺寸对车辆动力学模块软件具有预定义的影响，所有软件都可能受到影响。车轮尺寸可以在软件中抽象出来，并提供给依赖车轮尺寸来执行其功能的所有模块。

在一些实施方案中，类似的技术可以用于CAN接口处理。例如，配置文件可以表示软件或硬件差异。根据表示差异的字符串值，构建系统可以从存储器中的目录中选择正确的DBC文件。

在一些实施方案中，运行时软件变体可以基于车辆中设置的配置在运行时在每个模块中(例如，在ECU中)处理。当车辆中的配置发生更改时，即使模块上的软件保持不变，模块软件也会基于新配置以不同的方式进行操作。通过使用“if/then”或“switch”语句(例如，在C编程语言中)，可以在ECU源代码中跟踪运行时软件变体。构建时软件变体可以由软件构建系统使用编译时标志生成。可以为同一模块制作多个二进制文件，以支持不同的车辆配置。为了更改车辆上的软件操作，在车辆配置更改后，可以使用不同的软件对模块(例如，ECU)进行闪存。构建时变体可以通过变体配置图来跟踪和控制。变体配置图可以作为构建脚本的一部分存储在车辆的存储器中(例如，在软件GitHub存储库中)。在软件构建期间，生成的二进制码根据它们在车辆软件包内的变体进行结构化，然后将其上传并存储在变体库中。

在一些实施方案中，车辆生成ID可以被定义为特定平台的修订版。为了处理变体，可以基于在项目的构建配置中定义的那些ID来组合多个DBC文件。DBC文件可能会被平台分解，然后每个总线组合成一个DBC文件，并基于构建配置中定义的字段在构建之前放置在存储器中。操作系统可以基于接口变体生成接口抽象文件。以这种方式，可以生成被定义为处理来自多个外围设备的DBC文件的公共接口和车辆模型特定共性的文件夹。例如，可能存在用于公共DBC接口的文件夹以及用于使用不同版本的硬件的模型的接口的变体文件夹。随着平台之间的共性减少，文件夹结构可能最终更改为不再使用公共文件夹的格式。

一些实施方案包括一种用于在安装新硬件部件时更新车辆的方法(如图15a所示)，该方法包括：在步骤1510中使用车辆中的处理电路检测新硬件部件；使用处理电路识别由新硬件部件生成的数据与车辆的至少一个软件部件之间的关联1520；在步骤1530中确定是否需要更新的接口；以及如果需要，则在步骤1540中使用处理电路生成用于解译来自硬件部件的数据的更新的接口，其中更新的接口将由硬件部件提供的数据转换为抽象信息，并且其中更新的接口将抽象信息提供给车辆的至少一个软件部件。如果在步骤1520中不需要更新的接口，则该方法移动到步骤1540并且不采取任何动作。在一些实施方案中，由新硬件部件生成的数据包括数据库(DBC)文件。一些实施方案包括将更新的接口存储在接口库中，其中生成更新的接口包括从库中访问更新的接口。在一些实施方案中，基于新硬件部件的识别从库中选择更新的接口。一些实施方案包括由车辆的至少一个软件部件处理抽象信息，而无需考虑由新硬件部件生成的数据。在一些实施方案中，更新的接口用于至少一个软件部件和新硬件部件之间的双向通信。在一些实施方案中，生成更新的接口包括修改现有接口。

一些实施方案包括一种用于在安装新硬件部件时更新车辆的系统，该系统包括：新硬件部件；由新硬件部件生成的数据与车辆的至少一个软件部件之间的关联；和接口，该接口被配置为将来自硬件部件的数据转换为抽象信息，其中该接口将抽象信息提供给车辆的至少一个软件部件。在一些实施方案中，由新硬件部件生成的数据包括数据库(DBC)文件。一些实施方案包括接口库，其中存储更新的接口。一些实施方案包括新硬件部件的识别，其中基于新硬件部件的识别从库中选择更新的接口。在一些实施方案中，由车辆的至少一个软件部件处理抽象信息，而无需考虑由新硬件部件生成的数据。在一些实施方案中，更新的接口用于至少一个软件部件和新硬件部件之间的双向通信。在一些实施方案中，更新的接口是对现有接口的修改。

一些实施方案包括一种非暂态计算机可读介质，该非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，该非暂态计算机可读指令在被处理器执行时致使处理器：使用车辆中的处理电路检测新硬件部件；使用处理电路识别由新硬件部件生成的数据与车辆的至少一个软件部件之间的关联；以及使用处理电路生成用于解译来自硬件部件的数据的更新的接口，其中更新的接口将由硬件部件提供的数据转换为抽象信息，并且其中更新的接口将抽象信息提供给车辆的至少一个软件部件。在一些实施方案中，由新硬件部件生成的数据包括数据库(DBC)文件。一些实施方案包括致使处理器将更新的接口存储在接口库中，其中生成更新的接口包括从库中访问更新的接口。在一些实施方案中，基于新硬件部件的识别从库中选择更新的接口。一些实施方案包括致使处理器由车辆的至少一个软件部件处理抽象信息，而无需考虑由新硬件部件生成的数据。在一些实施方案中，更新的接口用于至少一个软件部件和新硬件部件之间的双向通信。

图16描绘了用于管理经由单个总线(例如，CAN总线)连接的不同模块(例如，硬件和/或软件)的时间同步的示例性系统。具体地，该技术可以应用于任何种类的基于多主总线的协议(例如，当总线上存在许多总线主节点时)。当总线上的多个节点必须具有引发数据传送的能力时，可以使用此类总线。例如，可以使用多主总线在外围设备和存储器之间传送数据，而无需使用CPU。

在示例性车辆中(例如，如图1至图3中所描绘)，多个节点(例如，ECU)可以连接到总线1600(例如，CAN总线或任何其他多主总线)，如图16所示。图16中的每个圆圈都可以表示节点1601、1602等。通常，各个节点(例如，ECU)可能需要知道时间度量，该时间度量在总线上是一致的。在一种方法中，可以指定(例如，随机)单个节点作为“时间服务器”。然后，此时间服务器节点可以在总线上广播其内部时钟。然后，所有其他节点都接收此广播消息并将其内部时钟与该消息同步。

然而，此先前解决方案并不考虑时间服务器在总线消息上设置时间的点与接收节点最终接收和处理该消息的时间之间的时间延迟。该延迟可能由若干可变延迟源引起。延迟源可以包括时间同步广播在可以通过硬件总线传输之前经过服务器的软件栈所需的时间。延迟源可以包括消息在总线的线路上传播所花费的时间(在使用仲裁协议的总线管理系统中，这可能是不确定的)。延迟源可以包括在客户端可以访问时间值之前客户端的软件栈处理所接收的消息所需的时间。由于这些原因，当客户端将其内部时钟更新为其刚刚在总线消息中所接收的时间时，它正在与过去的时间同步。在这种方法中，客户端的内部时钟将滞后于时间服务器节点的时间。一些节点可能并不关心这种相对较小的时间差(例如，节点1602和1603)，然而其他节点可能希望与服务器节点(1601)进行精确且紧的时间同步(例如，节点1604)。

另一种时间同步方法通过简单网络时间协议(SNTP)(RFC 1769，https://datatracker.ietf.org/doc/html/rfc1769)进行描述，该协议全文并入本文。在这种方法中，客户端将其本地时间在同步消息中发送到时间服务器。服务器使用包括客户端的本地时间以及服务器的本地时间的同步消息来答复。然后，客户端可以计算客户端和服务器之间的延迟(例如，通过减去时间戳)，并通过延迟值调整其时钟以实现更紧的同步。这种方法的不利之处在于它需要在每个节点和时间服务器之间进行点对点通信。大量此类消息可能会使总线饱和并降低总线性能。此外，一些节点可能不需要紧密同步，在这种情况下，它们仍会使总线充满完全不需要的同步消息。

图17和图18示出了节点同步的混合解决方案，其可以根据同一总线上具有不同需求的多个节点的要求实现松散同步和紧密同步。此方法提供了节点选择其时间同步级别的能力。通过被动地监听时间更新，可以保持低于标准级别的同步。通过主动请求时间更新，可以保持高级别的同步而不影响网络上的其他节点。如图17所示，服务器节点可以连续地(例如，周期性地或以其他特定间隔)传输(例如，通过在总线上广播)包括服务器的内部时间的消息。例如，该消息可以包括“Transmit”字段，该字段包括创建消息时服务器的内部时钟的时间值。例如，传输时间戳可以具有值“47.5ms”。

该消息在由时间客户端节点处理之前可以经历服务器栈延迟、线路延迟和客户端栈延迟，该时间客户端节点可以通过在接收到该消息时添加目标时间戳来修改该消息。例如，目标时间戳可以具有值“60ms”。然后，节点可以计算传输时间戳和目标时间戳之间的差值以调整其时钟。例如，节点可以将其时钟调整到“47.5ms”，以实现松散同步。每当客户端节点合适时(例如，每次接收到来自服务器的同步消息或仅使用一些广播消息时)，客户端节点可以执行此同步。

图17示出了需要紧密同步的节点与同一服务器之间的交互。在这种情况下，服务器还可以连续地(例如，周期性地或以其他特定间隔)传输(例如，通过在总线上广播)包括服务器的内部时间的消息。然而，服务器可以考虑由节点经由总线发送的同步请求。

例如，在图17中，需要紧密同步的节点可以使用节点的内部时钟发送同步请求，该同步请求包括传输时的时间戳1701。例如，传输字段可以包括值“56.5”(其为节点的本地时间)。节点可以保存传输字段的本地副本以供验证。

当时间服务器接收到这种请求时，其可以修改其下一个周期性发送的时间更新消息。在一些实施方案中，服务器可以在下一个更新消息之前接收若干紧密同步请求。在这种情况下，服务器可以仅处理这些请求中的一个请求(例如，第一个请求，或随机选择的一个请求)。具体地，服务器可以通过将所接收的消息的传输值放置到“始发”字段中来创建下一个同步更新消息。例如，“始发”字段可以包括值“56.5”。服务器还可以包括时间戳1702，该时间戳指示节点发送的消息何时被服务器使用服务器的时钟接收。例如，“接收”文件可以具有值“60”。然后，服务器将发送更新消息(例如，在最初计划时间或立即)，其中更新消息将包括基于服务器时钟的传输时间。例如，传输值可以被设置为“60.5”。

当客户端接收到同步消息时，它可以通过基于其自己的时钟将时间戳添加到目标字段中来修改该同步消息。当客户端从服务器接收到具有非零“始发”值的同步消息时，客户端可以将“始发”字段与由节点发送(并存储在节点的存储器中)的消息的初始“传输”时间进行比较。如果字段不匹配，则节点仍可以使用从服务器所接收的消息来进行松散同步(例如，如关于图16所描述)。如果字段匹配，则客户端可以执行紧密同步。

具体地，可以通过计算往返延迟1801来执行紧密同步，例如，其中往返延迟＝(“目标”值1802-“始发”值1803)-(“接收”值1804-“传输”值1805)，如图18所示。也就是说，客户端节点可以计算服务器接收和服务器传输之间的延迟、节点传输和节点接收之间的延迟并减去这些值。该节点还可以通过对以下项求平均来计算时钟偏移1806：(a)“始发”值1803(节点时钟)和接收时间1804(服务器时钟)之间的时间差；和(b)“传输值”1805(服务器时钟)和“目标”1802(节点时钟)之间的时间差。往返延迟和偏移值可以由节点使用来修改其本地时钟以使其与服务器时钟紧密匹配(例如，通过将往返延迟和时钟偏移添加到其内部时钟)。有利地，如果两个节点彼此同步，则它们可以使用来自服务器的相同消息来执行服务器紧密同步(因为它们的传输值将是相同的)。

另外，在一些具体实施中，节点可以存储所计算的时钟偏移和往返延迟的历史。如果历史指示稳定模式，则节点可以降低其请求紧密同步的频率或停止发送对紧密同步的请求，并且可以依赖历史值来执行同步。这可以进一步减少总线(例如，CAN总线)上的拥塞。

一些实施方案(诸如图18A所示)包括一种用于在第一客户端、第二客户端和时间服务器(该第一客户端、该第二客户端和该时间服务器各自与相应本地时钟相关联并且各自连接到总线)之间进行紧密同步的方法，该方法包括以下步骤：由时间服务器生成要通过总线传送的周期性同步消息1810；在时间服务器处通过总线接收同步消息，该同步消息包括来自第一客户端的对紧密同步的请求1820；响应接收到该同步消息，由时间服务器基于紧密同步请求来调整周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，该第一时间指示第一客户端何时传输同步消息；(b)第二时间，该第二时间指示服务器何时接收紧密同步请求；和(c)第三时间，该第三时间指示时间服务器何时发送周期性同步消息1830；由第一客户端基于经调整的周期性同步消息来执行紧密同步1840；以及由第二客户端基于经调整的周期性同步消息来执行松散同步1850。

图19至图21描绘了将用于测试设备(例如，集成电路)的汇编代码缝合在一起的示例。具体地，提供了用于创建经编译的机器可读代码(例如，汇编代码)的系统和方法，用于测试从不允许函数重载操作的语言(例如，C语言)编译的函数的多个版本。该设备可以为如图1至图3所示的车辆的任何电路。在一些实施方案中，该设备可以为任何合适的电子设备。

单元测试是安全软件开发的组成部分。例如，ISO26262标准强烈建议安全关键软件在预期运行代码的目标设备或电路上进行单元测试。为此，在测试期间，将软件提供给设备以在现有硬件上进行编译和/或加载。此类测试确保在设备测试中正确考虑任何编译器或硬件特定特征。

在一些具体实施中，待测试电路(例如，车辆的嵌入式电路)可以接收并安装整个应用程序作为汇编语言的单个编译的二进制代码。例如，对于所有应用程序，驱动器和必要的库可以在电路的单个存储器空间内编译成单个图像。然而，这样的要求使得难以对某些功能的所有输入进行详尽的测试。

在一个示例中，第一设备上的第一函数可能需要由第二设备产生的第二函数的输出。在这种情况下，为了详尽地测试第一设备上的第一函数的操作，测试可以由第二设备产生的第二函数提供的每个可能输出将是有益的。为了实现这一点，第二设备可以用代码闪存，其中第二函数被替换为假函数(也称为存根函数或模拟函数)，该假函数仅提供通过编程设置的值，或运行通过每个可能输出，而不提供真正的功能。例如，TCM可以具有需要来自ECM的每分钟转数(RPM)值的函数。在这种情况下，当测试TCM软件时，可能有益的是在ECM上伪造RPM设置函数，该函数迭代通过每个可能的RPM值。然而，这意味着，用于测试TCM的ECM最终必须重新闪存有用于测试其他函数的图像或包括返回实RPM值的实函数的实图像。这种创建和重新闪存多个二进制图像的过程可能很繁琐，并且如果使用了错误的图像，则可能会导致错误。

在一种方法中，可以使用函数重载。在这种情况下，一个函数可以存在多个版本，并且系统可以区分调用哪个函数(例如，基于函数调用的输入)。然而，多个嵌入式系统不接受从此类语言编译的代码，并且可能接受来自不支持重载的语言(例如，C编程语言)的代码。

使用此类语言时，对于任何给定图像，可能仅存在函数的一个副本。这意味着，如果一个函数需要为假测试函数进行存根以测试另一函数，则该存根函数是整个图像中的唯一副本。例如，如果下一个被测单元是存根函数，则它不能与前一个单元共存于同一图像中。实际上，这意味着必须为不同的被测单元编译多个图像。将这些多个图像闪存到目标硬件上并收集结果的过程非常繁琐。

为了克服这个问题，提供了一种将所有需要的图像(包括实图像和所有带有存根函数的图像)分别编译成汇编代码的方法。然后，将汇编代码缝合在一起成为单个超级图像。在缝合期间，对每个子图像进行调整，以适应它们现在位于不同地址空间的事实。这允许闪存可以用于所有测试和生产的单个文件。

此解决方案不需要在语言之上使用任何附加技术，也不需要函数重载(例如，C编程语言)，并且不对目标硬件施加任何约束。例如，该解决方案不需要使用存储器管理单元，新的操作系统或不同的编程语言。该解决方案广泛适用于所有类型的合适硬件，并可以大大提高目标单元测试的效率。此外，该解决方案促进了单元测试之间的隔离，这是适当单元测试的核心职责，并且迄今为止难以使用没有函数重载的语言来实现。

可以使用以下步骤来执行用于基于编译图像创建超级图像的方法。需要使用存根函数的每个单元测试代码都被编译为单个图像。然后，编译最终测试套件所需的尽可能多的不同图像。所有编译的图像都被馈送到大型图像创建程序(MICP)中。对于每个图像，MICP定位该图像在存储器中的位置，使其不与其他图像的存储器要求冲突。然后，对于每个图像，MICP调整其中的机器指令以反映新的最终地址位置。接下来，作为最终大型图像创建的一部分，MICP创建进入大型图像内的每个子图像以及单元测试框架的入口点表，该大型图像是所有子图像的组合。

接着，将大型图像闪存到目标硬件上。此时，可以运行硬件测试以收集测试数据。快速执行目标单元测试的能力降低了他们的进入壁垒，因此更容易获得ISO26262 ASIL认证，并允许更快地生产ASIL级软件。

图19示出用于测试第一单元的第二单元的示例性代码。第二单元的代码可以包括函数Function 2的代码，该函数是可以产生可变输出的实函数。

图20示出正在测试的所使用的第一单元的示例性代码。可以看出，函数单元32_t_to_test_one包括在代码行111对Function 2的函数调用。如上所述，可能有利的是将实函数Function 2替换为存根函数或假函数，该函数返回程序员设置的值(例如，迭代通过所有可能的输出)。

图21示出了由MICP产生的示例性结果，该MICP将图19的代码的图像和图20的代码的图像缝合在单个大型图像2101内。值得注意的是，大型图像2101包括跳转表，该跳转表使子图像一2102中的函数Function 1(在行105)除了在行193调用伪函数之外，还能够在行246调用实函数Function 2。函数Function 2的行号可能已被MICP更改，以避免存储器冲突。本领域技术人员将注意到，虽然图19至图21示出了C语言代码，但可能已经使用任何其他编程语言(例如，特定于被测试硬件的汇编语言)。

本文描述的系统和方法不限于测试的使用。只要函数重载有益，包括可读性或节省存储器空间，以及其他用途，都可以使用该系统。

一些实施方案可以包括一种用于函数重载的方法(如图21a所示)，该方法包括：编译函数的第一版本的第一图像2110；编译函数的第二版本的第二图像2120；以及通过将定义函数的第一版本的代码和定义函数的第二版本的代码放置到存储器分区中来生成缝合的超级图像，其中定义函数的第二版本的代码被调整为与函数的第一版本的代码不冲突，并且生成表，该表用于选择性地调用函数的第一版本和函数的第二版本中的任一者2130。在一些实施方案中，函数的第一版本和函数的第二版本以不允许函数重载的代码编写。在一些实施方案中，函数的第一版本和函数的第二版本以C代码编写。在一些实施方案中，存储器分区位于车辆内。在一些实施方案中，该表为函数的第一版本和函数的第二版本中的每一者定义相应的存储器地址。在一些实施方案中，函数的第一版本的第一图像包括第一汇编代码，而函数的第二版本的第二图像包括第二汇编代码。一些实施方案还包括基于该表调用缝合的超级图像中的函数的每个版本。

前述内容只是举例说明本公开的原理，并且在不脱离本公开的范围的情况下，本领域的技术人员可作出各种修改。上述实施方案是出于举例说明而非限制的目的而呈现的。本公开还可采用除本文明确描述的那些形式之外的许多形式。因此，应当强调的是，本公开不限于明确公开的方法、系统和装置，而是旨在包括其变型和修改，这些变型和修改在以下段落的实质内。

Claims (18)

1.一种用于在第一客户端、第二客户端和时间服务器之间进行第一类型的同步的系统，所述第一客户端、所述第二客户端和所述时间服务器各自与相应本地时钟相关联，所述系统包括：

连接到总线的所述时间服务器，

连接到所述总线的所述第一客户端，

连接到所述总线的所述第二客户端，

其中所述第一客户端被配置为通过在所述总线上传输同步消息来请求与所述时间服务器的第一类型的同步，其中：

所述时间服务器被配置为生成在所述总线上传送的周期性同步消息，

时间服务器客户端被配置为基于来自所述第一客户端的所述第一类型的同步请求来调整所述周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，所述第一时间指示所述第一客户端何时传输所述同步消息；(b)第二时间，所述第二时间指示所述服务器何时接收所述第一类型的同步请求；和(c)第三时间，所述第三时间指示所述时间服务器何时发送所述周期性同步消息，

所述第一客户端被配置为基于所调整的周期性同步消息来执行所述第一类型的同步，并且

所述第二客户端被配置为基于所调整的周期性同步消息来执行第二类型的同步。

2.根据权利要求1所述的系统，其中所述第一客户端被进一步配置为基于所调整的周期性同步消息的内容和所调整的周期性同步消息的接收时间来执行所述第一类型的同步。

3.根据权利要求1所述的系统，其中所述第一客户端、所述第二客户端和所述时间服务器位于车辆上。

4.根据权利要求1所述的系统，其中所述同步消息包括指示所述第一时间的数据。

5.根据权利要求1所述的系统，还包括用于存储关于所述时间服务器和所述第一客户端之间的延迟的信息的存储器。

6.根据权利要求5所述的系统，还包括处理电路，所述处理电路基于所述延迟确定模式并基于所述模式致使在所述第一客户端和所述时间服务器之间发生同步。

7.一种用于在第一客户端、第二客户端和时间服务器之间进行第一类型的同步的方法，所述第一客户端、所述第二客户端和所述时间服务器各自与相应本地时钟相关联并且各自连接到总线，所述方法包括：

由所述时间服务器生成要通过所述总线传送的周期性同步消息；

在所述时间服务器处通过所述总线接收同步消息，所述同步消息包括来自所述第一客户端的对第一类型的同步的请求；

响应于接收到所述同步消息，由所述时间服务器基于所述第一类型的同步请求来调整所述周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，所述第一时间指示所述第一客户端何时传输所述同步消息；(b)第二时间，所述第二时间指示所述服务器何时接收所述第一类型的同步请求；和(c)第三时间，所述第三时间指示所述时间服务器何时发送所述周期性同步消息；

由所述第一客户端基于所调整的周期性同步消息来执行第一类型的同步；以及

由所述第二客户端基于所调整的周期性同步消息来执行第二类型的同步。

8.根据权利要求7所述的方法，还包括基于所调整的周期性同步消息的内容和所调整的周期性同步消息的接收时间来执行所述第一类型的同步。

9.根据权利要求7所述的方法，其中所述第一客户端、所述第二客户端和所述时间服务器位于车辆上。

10.根据权利要求7所述的方法，其中所述同步消息包括指示所述第一时间的数据。

11.根据权利要求7所述的方法，还包括将关于所述时间服务器和所述第一客户端之间的延迟的信息存储在存储器中。

12.根据权利要求11所述的方法，还包括由处理电路基于所述延迟确定模式并基于所述模式致使在所述第一客户端和所述时间服务器之间发生同步。

13.一种非暂态计算机可读介质，所述非暂态计算机可读介质具有编码在其上的非暂态计算机可读指令，所述非暂态计算机可读指令在被处理器执行时致使所述处理器：

由所述时间服务器生成要通过所述总线传送的周期性同步消息；

在所述时间服务器处通过所述总线接收同步消息，所述同步消息包括来自所述第一客户端的对第一类型的同步的请求；

响应于接收到所述同步消息，由所述时间服务器基于所述第一类型的同步请求来调整所述周期性同步消息，方法是调整下一个周期性同步消息以使其包括：(a)第一时间，所述第一时间指示所述第一客户端何时传输所述同步消息；(b)第二时间，所述第二时间指示所述服务器何时接收所述第一类型的同步请求；和(c)第三时间，所述第三时间指示所述时间服务器何时发送所述周期性同步消息；

由所述第一客户端基于所调整的周期性同步消息来执行所述第一类型的同步；以及

由所述第二客户端基于所调整的周期性同步消息来执行第二类型的同步。

14.根据权利要求13所述的计算机可读介质，还包括致使所述处理器基于所调整的周期性同步消息的内容和所调整的周期性同步消息的接收时间来执行所述第一类型的同步。

15.根据权利要求13所述的计算机可读介质，其中所述第一客户端、所述第二客户端和所述时间服务器位于车辆上。

16.根据权利要求13所述的计算机可读介质，其中所述同步消息包括指示所述第一时间的数据。

17.根据权利要求13所述的计算机可读介质，还包括致使所述处理器将关于所述时间服务器和所述第一客户端之间的延迟的信息存储在存储器中。

18.根据权利要求13所述的计算机可读介质，还包括致使所述处理器基于所述延迟确定模式并基于所述模式致使在所述第一客户端和所述时间服务器之间发生同步。

Images