车载电子电器架构 —— 多核处理器刷写策略

车载电子电器架构 —— 多核处理器刷写策略

我是穿拖鞋的汉子，魔都中坚持长期主义的汽车电子工程师。

老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工程师：

屏蔽力是信息过载时代一个人的特殊竞争力，任何消耗你的人和事，多看一眼都是你的不对。非必要不费力证明自己，无利益不试图说服别人，是精神上的节能减排。
无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事.而不是让内心的烦躁、焦虑、毁掉你本就不多的热情和定力。

文章大体有如下内容：

1、背景信息

2、多核芯片刷写策略

3、多处理器验证策略

4、域控制器和网关(GW)

一、背景信息

本文是针对多处理器(比如 MCU+ DSP)，对于刷写数据验证策略。

在日常电子电器架构对整车控制器做项目kick off时，每个功能件供应商定点会报自己的技术方案，技术方案中就会包括该功能件的硬件框架：

车载ECU（电子控制单元）多处理器框架是一种用于汽车电子控制系统的架构，它采用多个处理器或处理核心来协同完成复杂的控制任务。这种框架旨在提高系统的可靠性、性能和可扩展性，以适应现代汽车对于智能化、自动化和安全性方面的需求。

在车载ECU多处理器框架中，通常包含一个主处理器和多个协处理器或处理核心。主处理器负责整个系统的控制和协调，而协处理器则负责处理特定的任务或功能。这些处理器之间通过高速通信接口（如CAN总线、LIN总线等）进行数据传输和协同工作。

车载ECU多处理器框架的优点包括：

-> 1、提高系统的可靠性：通过采用多个处理器，可以实现冗余设计，当某个处理器发生故障时，其他处理器可以接管其任务，保证系统的正常运行。

-> 2、提高系统的性能：多个处理器可以并行处理任务，从而加快处理速度，提高系统的响应速度和吞吐量。

-> 3、提高系统的可扩展性：可以根据需要增加或减少处理器数量，以适应不同车型和配置的需求。

-> 4、车载ECU多处理器框架的实现需要考虑多个方面的问题，如处理器之间的任务分配、通信协议的设计、系统同步和时序控制等。同时，还需要考虑如何保证系统的实时性和安全性，以满足汽车行业的严格要求。

在实际应用中，车载ECU多处理器框架已经广泛应用于各种汽车控制系统中，如发动机控制、车身控制、底盘控制、驾驶辅助系统等。随着汽车智能化和自动化程度的不断提高，车载ECU多处理器框架将会在未来发挥更加重要的作用。

二、多核芯片刷写策略

在此文中，主处理器用于定义具有用于软件下载的网络接口的微控制器。该要求适用于此类型硬件框架的ECU，其中次级处理器的所有软件不直接发送到次级处理器，而是寻址到主处理器，即从测试人员的角度来看，它被视为一个单个ECU。主处理器一词用于定义具有用于软件下载的网络接口的微控制器。本文中的要求适用于所有软件不是直接发送到辅助处理器而是发送到主处理器的ECU，即从测试器的角度来看，它被视为一个单一的ECU。

这段文本进一步解释了主处理器的含义。它指出，主处理器是指具有与网络接口的微控制器，用于软件下载。此外，文本还强调了本节中的要求适用于所有软件不是直接发送到辅助处理器而是发送到主处理器的ECU的情况。这意味着从测试器的角度来看，主处理器和辅助处理器被视为一个单一的ECU（对外只有一个诊断ID，对Tester或者刷写上位机只有一个整体）。

这种配置通常用于汽车电子控制单元(ECU)，其中主处理器负责与外部网络通信和软件下载，而辅助处理器则执行其他功能。在进行测试和验证时，需要确保主处理器和辅助处理器之间的协调和通信，以确保整个 ECU 的正常运行和安全性

总之，本文本强调了主处理器在ECU中的重要性和上下文，并指出了本节要求适用于特定类型的ECU配置。这对于进行有效的测试和验证以及确保ECU的安全性和稳定性至关重要。

车载ECU多处理器框架的刷写策略涉及到如何有效地更新、升级或修复ECU中的软件。在多处理器环境中，刷写策略需要确保数据的完整性、一致性和安全性，同时最小化对车辆运行的影响。以下是一些建议的刷写策略：

-> 分区分步刷写：

将ECU的存储空间划分为多个区域（如引导区、应用程序区、数据区等）。

分步刷写意味着每次只更新一个或几个区域，而不是整个ECU的软件。

这种方法可以减少刷写失败的风险，因为即使某个区域的刷写出现问题，其他区域仍然可以正常工作。

-> 冗余设计：

在多处理器框架中，可以考虑使用冗余的ECU或处理器来确保刷写过程中的系统可用性。

当一个ECU正在进行刷写时，其他冗余的ECU可以继续执行关键任务。

-> 刷写前校验：

在开始刷写过程之前，对要刷入的固件或软件进行校验（如CRC校验、数字签名验证等）。

确保刷写数据的完整性和来源的合法性，防止恶意软件或损坏的数据被刷入。

-> 刷写过程中断保护：

设计刷写策略以应对可能的刷写中断（如电源中断、通信故障等）。

使用事务性刷写方法，确保在中断发生时能够回滚到之前的状态或安全地中止刷写过程。

-> 刷写后验证：

刷写完成后，对新刷入的软件进行验证，确保其正确运行。

验证过程可以包括功能测试、性能测试和安全性测试。

-> 远程与本地刷写结合：

支持远程OTA（Over-The-Air）更新，使ECU能够通过车载通信网络接收并应用新的软件版本。

同时保留本地刷写接口（如USB、CAN诊断等），以便在需要时进行手动刷写。

-> 回退策略：

如果新刷入的软件出现问题，应有一个回退到之前稳定版本的策略。

这可能需要保留旧版本软件的备份，并在必要时能够恢复。

-> 安全性考虑：

在整个刷写过程中，确保数据的安全传输和存储。

###c 使用加密技术保护固件或软件不被未经授权的访问或篡改。

-> 用户通知与授权：

在刷写开始前，通知用户并获取必要的授权。

提供刷写进度的反馈，并在完成后通知用户。

在实施车载ECU多处理器框架的刷写策略时，还应考虑到不同ECU之间的依赖关系、刷写顺序以及可能的相互影响。此外，刷写策略应与车辆的整体诊断和维护策略相结合，以确保系统的长期稳定运行。

主处理器的引导加载程序必须能够识别属于辅助处理器上内存设备的软件部件,通常通过使用地址偏移量，并相应地传输它。建议主处理器同时保留一些有关辅助处理器内存布局的信息，以便在将数据传输到辅助处理器之前进行第一次过滤。适用的原则是逻辑块应由执行逻辑块的实体进行验证。

主处理器的引导加载程序（Bootloader）必须能够识别属于辅助处理器内存设备的软件部分，通常通过使用地址偏移量来实现，并相应地传输它。建议主处理器保留有关辅助处理器内存布局的一些信息，以便在将数据传输到辅助处理器之前进行初步筛选。应用的原则是逻辑块应由执行它的实体进行验证。

这段文本强调了主处理器引导加载程序在处理与辅助处理器相关的软件部分时的关键作用它解释了如何通过使用地址偏移量来识别属于辅助处理器的软件部分，并提到了在数据传输到辅助处理器之前进行初步筛选的建议。

此外，本文还强调了逻辑块应由执行它的实体进行验证的原则。这意味着每个逻辑块都应由在其上执行操作的处理器进行验证，以确保数据的完整性和正确性。这种验证可以防止潜在的错误或恶意软件影响辅助处理器的正常运行。

总之，这段文本强调了主处理器引导加载程序在处理与辅助处理器相关的软件部分时的关键作用，并提出了相应的建议和原则，以确保系统的安全性和稳定性。

三、多处理器验证策略

从安全角度来看，软件应在目标处理器上进行最终验证。这将降低软件在传输过程中被算改的风险。这样就强调了软件最终验证的重要性，以降低软件在传输过程中被篡改的风险。

通过在目标处理器上进行最终验证，可以确保软件在到达其预期目的地时是完整和未被篡改的。这有助于提高系统的安全性和稳定性，并减少潜在的安全威胁。

此外，文本还提到了安全角度的重要性，强调了在整个软件生命周期中应采取的安全措施。这包括开发过程中的安全编码实践、测试和验证阶段的安全性检查，以及部署阶段的安全部署和防护措施。通过在整个软件生命周期中采取综合的安全措施，可以进一步保护系统的安全性和完整性。

逻辑块应由目标处理器分别进行验证，即由主处理器或辅助处理器进行验证

注意:实际的ECU实现高度依赖于硬件，例如处理器的能力和内部接口

这段文本再次强调了逻辑块验证的重要性,并指出应由目标处理器(主处理器或辅助处理器负责进行验证。验证过程确保了逻辑块的完整性和正确性，从而保证了系统的安全性和稳定性。

同时，文本还提到了实际 ECU 实现与硬件的紧密关系。不同的硬件实现可能会有不同的处理器能力和内部接口，这将对逻辑块的验证方式和效果产生影响。因此，在进行逻辑块验证时，需要充分考虑硬件的特点和限制，以确保验证的有效性和可靠性

比如在吉利体系，辅助引导加载程序（SBL）是一个特殊情况，其中需要在单个软件部分中处理两个(主/辅助处理器)不同的内存设备。具有附加处理器的ECU的SBL验证。

该需求描述了辅助引导加载程序 (SBL)的特殊情况，其中需要处理两个不同的内存设备(主处理器和辅助处理器)。它进一步提到，这种情况下的软件部分应具有一种机制，以区分并正确处理这两个处理器。

文本中还提到了一个图表，该图表描述了如何验证具有附加处理器的ECU的SBL。这个图表可能包含有关如何验证SBL的详细步骤或过程，以便正确处理两个不同的内存设备。

总之，这段文本强调了在具有两个不同内存设备的ECU中，需要正确处理和验证SBL的特殊情况，以确保系统的正常运行和安全性。

主处理器的责任:主处理器将验证验证块表的真实性，并在其内存范围内验证数据块。主处理器将向辅助处理器请求验证结果，即针对发送给辅助处理器的数据块。因此，主处理器必须转发验证块的副本、其签名以及属于辅助处理器的所有数据块。

辅助处理器的责任:辅助处理器也将验证验证块表的真实性，但不验证验证块中的数据块数量。实际下载的数据块数量(不包括验证块)应为1。辅助处理器应验证下载数据块的起始地址、长度和哈希值是否与验证块中定义的值相同，并应向主处理器报告验证结果。

这段文本详细描述了主处理器和辅助处理器的责任，以确保软件的安全性和完整性。主处理器负责验证验证块表的真实性和数据块的完整性，并转发必要的验证块和数据块。辅助处理器则负责验证下载数据块的起始地址、长度和哈希值是否与验证块中定义的值一致，并报告验证结果给主处理器。

这种分工合作的方式确保了每个处理器都负责其范围内的验证任务,从而提高了整个系统的安全性和稳定性。

主处理器对 SBL执行的验证定义如下:

主处理器负责验证 SBL的真实性、完整性和正确性。首先，主处理器会验证SBL的签名，以确保其来源的可信度和未被算改。其次，主处理器会检查 SBL的完整性，包括验证其内部数据结构的一致性和逻辑的正确性。最后，主处理器还会验证SBL的功能正确性，即确保 SBL能够正确地引导并加载系统。

这些验证步骤确保了 SBL 的安全性和可靠性，从而保证了整个系统的稳定性和安全性。通过主处理器的严格验证，可以防止恶意软件或算改后的 SBL进入系统，并确保系统的正常启动和运行。

主处理器应(至少)验证专为主处理器自身内存空间的数据块。主处理器应将属于辅助处理器的数据块与验证块表的副本一起转发注意:除此例外情况外，验证应与任何其他逻辑块一样进行 (例如，包括签名验证等)。

辅助处理器对SBL执行的验证定义如下:

辅助处理器负责验证SBL的特定部分，以确保与辅助处理器相关的数据块正确无误。首先，辅助处理器会验证其负责的数据块的完整性，包括检查数据块的起始地址、长度和哈希值是否与验证块中定义的值一致。其次，辅助处理器还会验证这些数据块的签名，以确保数据的来源可信且未被篡改。最后，辅助处理器会将这些验辅助处理器负责验证 SBL 的特定部分，以确保与辅助处理器相关的数据块正确无误。首先，辅助处理器会验证其负责的数据块的完整性，包括检查数据块的起始地址、长度和哈希值是否与验证块中定义的值一致。其次，辅助处理器还会验证这些数据块的签名，以确保数据的来源可信且未被篡改。最后，辅助处理器会将这些验证结果报告给主处理器，以便主处理器可以进一步处理或采取必要的措施。

通过辅助处理器的验证，可以确保与辅助处理器相关的数据块正确无误地加载到系统中，从而提高系统的安全性和稳定性。这种分工合作的方式能够最大限度地减少因错误或恶意软件引起的系统故障或安全漏洞。

辅助处理器首先应验证验VBT，然后在其内存空间内验证下载的数据块。辅助处理器不会接收到验证块表中定义的所有数据块。

搁笔分享完毕！

愿你我相信时间的力量

做一个长期主义者