在 AURIX TC397 项目中看到 SCR、PMS、VEVRSB、TLF35584 和 Standby 等概念时，很容易产生两个误解：一是认为芯片既然集成了 SCR，项目就必须使用；二是认为 SCR 与 TLF35584 都涉及待机和唤醒，因此两者功能重复。
实际上，SCR 是 TC397 内部可选的低功耗可编程控制器，TLF35584 是外部电源管理与安全监控芯片。两者确实在“待机、唤醒、定时、监控”这些应用目标上存在交集，但承担的是不同层次的职责：
TLF35584 决定电源如何提供、关闭、恢复并监督系统供电安全；SCR 决定主系统停止运行期间还要执行什么逻辑，以及什么时候值得唤醒主系统。
一次多核启动异常最容易被“当前停在哪里”带偏。
调试器第一次停下时，CPU0 位于 HSM IPC 的 ready-wait；CPU1～CPU5 的 PC 都显示为 0xAFFFC000，SYSCON.BHALT=1。继续 Reset、Run 和单步后，CPU0 又进入 0xAFFFBxxx 的 Boot ROM 区域；Run 之后还会重新落回 0xAFFFB296。表面上看，现场似乎同时指向 HSM、从核启动、Boot ROM、看门狗和时钟初始化五个方向。
最后，板子在一次 Reset 后恢复了正常运行，却没有留下一个可以复现的“修复动作”。
一条 CAN 时间同步报文在 DBC 里有完整的 CAN ID、DLC、周期、CRC、Counter 和时间字段；把它导入 AUTOSAR 配置工具后，却可能先出现一组看起来像普通 COM Signal 的派生对象，最终配置里这些对象又被移除，而同一个 PDU 实际被 CanTSyn 直接挂到了 CanIf 上。
如果只从“报文有没有被解析出来”这个角度看，这种现象很容易被归结为“DBC 不支持时间同步”或者“DaVinci 解析错了”。但这两个判断都不够准确。
真正的问题是：DBC 描述的主要是总线上“传了什么”，而 AUTOSAR 系统模型还需要知道“这个通信对象是什么、属于谁、经过谁、为什么这样配置”。 对普通 CAN Signal，这两种视角往往能重合；一旦进入 CanTSyn、SecOC、CanTp、CanNm、SOME/IP 等领域，两者之间的抽象层差异就会迅速暴露出来。
SecureBoot 经常被概括成一句话：设备启动之前先验证固件，验证通过才允许执行。
这句话没有错，但真正进入一个量产 ECU 工程后，很快会遇到一连串更具体的问题：谁先启动？谁负责验证？验证对象是整个镜像，还是一张描述镜像的清单？数字签名验证和 Hash 比较为什么会同时存在？为什么系统还要把一份 Reference Hash 存进 NvM？Reference Hash 第一次又是谁建立的？如果它丢失了，系统应该重新认证，还是直接“学习”当前内容？
这些问题如果没有放到完整启动链里理解，很容易在阅读 SecureBoot 代码时陷入局部：看到 HashAvailable，却不知道它为什么存在；看到 SignatureVerify，却不知道它在整条信任链中的位置；看到一个“让 ECU 恢复启动”的补丁，也很难判断它只是修复了状态机，还是同时改变了信任建立规则。
在 AUTOSAR COM 的配置里，ComIPduSignalProcessing 看起来只是一个很简单的选择：
IMMEDIATE
DEFERRED在AUTOSAR经典平台（Classic Platform，CP）的软件架构中，非易失性内存管理器（NvM，Non-Volatile Memory Manager）是基础软件服务层中的关键模块。NvM模块提供统一的接口供应用软件组件（SWC）和其他基础软件模块访问永久存储数据（例如读取和写入服务），负责管理EEPROM、闪存等非易失性存储介质上的数据。按照AUTOSAR标准，只有通过NvM模块才能访问NV存储，以确保数据一致性和底层存储的抽象。
随着汽车电子功能的复杂化和持久化数据需求的增长，应用SWC需要频繁保存各类配置参数、故障码、计数器和标定数据等以保证断电不丢失。但直接令每个SWC调用NvM服务，可能会引入如下问题：
在汽车ECU（Electronic Control Unit，电子控制单元）软件开发过程中，详细设计文档（Software Detailed Design Document，简称 SDD 或 SDDD）是一项关键的技术文档。它位于需求分析和代码实现之间，起着承上启下的桥梁作用。详细设计文档通过精确描述软件系统的具体实现方案，为开发团队提供可执行的施工蓝图，确保抽象的需求能够准确地转化为可落实的代码实现。
没有高质量的详细设计文档，团队往往会遇到以下痛点：
嵌入式汽车软件正变得日益复杂，ECU（电子控制单元）内部通常集成了数十个软件模块，每个模块承担不同功能。对于嵌入式开发人员、架构设计人员以及功能安全和ASPICE实施人员来说，编写模块架构设计文档是确保软件质量和满足行业标准的关键一步。良好的模块设计文档有助于澄清模块的职责边界、接口、行为和资源需求，使团队在开发和集成过程中有据可循。此外，清晰完善的设计文档也是通过Automotive SPICE审核和功能安全评估的必要支撑。本指南将介绍如何撰写模块架构设计文档，涵盖通用ECU软件功能模块的架构说明、ASPICE SWE.2 软件架构设计要求，以及一个完整的模块设计文档模板。最后，我们将通过几个典型模块（如SoAd、CanIf和诊断服务模块）的示例章节点缀说明，以图表和代码片段演示如何运用文档模板撰写实际内容。
作为一名嵌入式软件从业者，在汽车 ECU 软件开发中编写高质量的软件架构文档是确保项目成功和符合行业标准（如 ASPICE 与 ISO 26262）的关键步骤。本文将从实践操作、标准要求、方法论与最佳实践等角度，详细讲解如何在软件架构设计阶段（ASPICE SWE.2）撰写一份系统架构文档。
在软件架构设计阶段，产出物是一份详细的软件架构设计文档。该文档用于描述ECU软件的整体结构、模块组成、接口关系和动态行为等，为后续详细设计和实现提供蓝图。下面提供一个标准的软件架构文档章节结构以及各章节编写要点，帮助您快速上手撰写：
本福特定律（Benford’s Law，也常译本福德定律）描述了一个反直觉现象：在很多现实世界的数值数据里，第一位非零数字并不会平均出现，而是“1 更常见，9 更少见”。这条规律最早可追溯到 Newcomb（1881），随后由 Benford（1938）通过跨领域数据系统化验证而广为人知。
若首位非零数字为 ，本福特定律给出：
因此首位数字的大致比例为：1（约 30.1%）、2（约 17.6%）……9（约 4.6%）。