在车载嵌入式项目中，有一类问题非常容易把排查方向带偏：现象发生在通信接收侧，最终修复却改了发送侧配置；修改量很小，甚至只是一个枚举值；修改后问题确实消失，但继续沿源码、任务和硬件资源往下追，会发现实际机制和最初的“根因描述”并不完全一致。
本文以一次 SecOC Tx 从 IMMEDIATE 调整为 DEFERRED 的历史修复为背景，总结一套更通用的排查方法：
复杂实时系统的问题，不要只按“模块”排查，而要沿着执行上下文、共享资源和时序依赖去还原。
原创2026/9/30大约 9 分钟
在 AURIX TC397 项目中看到 SCR、PMS、VEVRSB、TLF35584 和 Standby 等概念时，很容易产生两个误解：一是认为芯片既然集成了 SCR，项目就必须使用；二是认为 SCR 与 TLF35584 都涉及待机和唤醒，因此两者功能重复。
实际上，SCR 是 TC397 内部可选的低功耗可编程控制器，TLF35584 是外部电源管理与安全监控芯片。两者确实在“待机、唤醒、定时、监控”这些应用目标上存在交集，但承担的是不同层次的职责：
TLF35584 决定电源如何提供、关闭、恢复并监督系统供电安全；SCR 决定主系统停止运行期间还要执行什么逻辑，以及什么时候值得唤醒主系统。
原创2026/8/25大约 17 分钟
一次多核启动异常最容易被“当前停在哪里”带偏。
调试器第一次停下时，CPU0 位于 HSM IPC 的 ready-wait；CPU1～CPU5 的 PC 都显示为 0xAFFFC000，SYSCON.BHALT=1。继续 Reset、Run 和单步后，CPU0 又进入 0xAFFFBxxx 的 Boot ROM 区域；Run 之后还会重新落回 0xAFFFB296。表面上看，现场似乎同时指向 HSM、从核启动、Boot ROM、看门狗和时钟初始化五个方向。
最后，板子在一次 Reset 后恢复了正常运行，却没有留下一个可以复现的“修复动作”。
原创2026/8/24大约 22 分钟
一条 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 等领域，两者之间的抽象层差异就会迅速暴露出来。
原创2026/8/19大约 47 分钟
SecureBoot 经常被概括成一句话：设备启动之前先验证固件，验证通过才允许执行。
这句话没有错，但真正进入一个量产 ECU 工程后，很快会遇到一连串更具体的问题：谁先启动？谁负责验证？验证对象是整个镜像，还是一张描述镜像的清单？数字签名验证和 Hash 比较为什么会同时存在？为什么系统还要把一份 Reference Hash 存进 NvM？Reference Hash 第一次又是谁建立的？如果它丢失了，系统应该重新认证，还是直接“学习”当前内容？
这些问题如果没有放到完整启动链里理解，很容易在阅读 SecureBoot 代码时陷入局部：看到 HashAvailable，却不知道它为什么存在；看到 SignatureVerify，却不知道它在整条信任链中的位置；看到一个“让 ECU 恢复启动”的补丁，也很难判断它只是修复了状态机，还是同时改变了信任建立规则。
原创2026/8/17大约 18 分钟
在 AUTOSAR COM 的配置里，ComIPduSignalProcessing 看起来只是一个很简单的选择：
IMMEDIATE
DEFERRED原创2026/8/14大约 18 分钟
引言与背景
在AUTOSAR经典平台（Classic Platform，CP）的软件架构中，非易失性内存管理器（NvM，Non-Volatile Memory Manager）是基础软件服务层中的关键模块。NvM模块提供统一的接口供应用软件组件（SWC）和其他基础软件模块访问永久存储数据（例如读取和写入服务），负责管理EEPROM、闪存等非易失性存储介质上的数据。按照AUTOSAR标准，只有通过NvM模块才能访问NV存储，以确保数据一致性和底层存储的抽象。
随着汽车电子功能的复杂化和持久化数据需求的增长，应用SWC需要频繁保存各类配置参数、故障码、计数器和标定数据等以保证断电不丢失。但直接令每个SWC调用NvM服务，可能会引入如下问题：
原创2026/1/20大约 97 分钟
1. 引言
在汽车ECU（Electronic Control Unit，电子控制单元）软件开发过程中，详细设计文档（Software Detailed Design Document，简称 SDD 或 SDDD）是一项关键的技术文档。它位于需求分析和代码实现之间，起着承上启下的桥梁作用。详细设计文档通过精确描述软件系统的具体实现方案，为开发团队提供可执行的施工蓝图，确保抽象的需求能够准确地转化为可落实的代码实现。
没有高质量的详细设计文档，团队往往会遇到以下痛点：
- 代码与需求脱节：如果开发人员对需求理解不充分，容易导致实现偏离最初目标，最终造成大量的返工。实践中，超过25%的车身电子功能返工源于需求理解偏差。详细设计文档通过需求到设计的双向追溯，确保每项软件需求都有对应的设计单元，从源头上降低需求误解的风险。
- 团队知识孤岛：在大型汽车软件项目中，不同子团队各自为战，容易形成知识孤岛。例如，硬件工程师可能不了解软件对通信矩阵的特殊要求，核心开发人员一旦离职，其掌握的模块实现细节可能无人知晓。详细设计文档以结构化的形式显性记录模块的设计细节和参考资料，建立统一的术语和接口规范，方便新老成员共享知识、沟通协作。
- 维护成本高昂：没有文档的指导，软件架构会在迭代中逐渐偏离初衷，出现“架构腐化”现象。例如，为快速支持新需求而随意修改代码，可能造成原本独立的模块变得高度耦合，维护一个功能却影响另一个功能。详细设计文档通过清晰的模块边界和设计原则约束开发，提高代码可读性，降低模块间耦合度，从而控制后期维护的风险和成本。
原创2026/1/6大约 45 分钟
简介
嵌入式汽车软件正变得日益复杂，ECU（电子控制单元）内部通常集成了数十个软件模块，每个模块承担不同功能。对于嵌入式开发人员、架构设计人员以及功能安全和ASPICE实施人员来说，编写模块架构设计文档是确保软件质量和满足行业标准的关键一步。良好的模块设计文档有助于澄清模块的职责边界、接口、行为和资源需求，使团队在开发和集成过程中有据可循。此外，清晰完善的设计文档也是通过Automotive SPICE审核和功能安全评估的必要支撑。本指南将介绍如何撰写模块架构设计文档，涵盖通用ECU软件功能模块的架构说明、ASPICE SWE.2 软件架构设计要求，以及一个完整的模块设计文档模板。最后，我们将通过几个典型模块（如SoAd、CanIf和诊断服务模块）的示例章节点缀说明，以图表和代码片段演示如何运用文档模板撰写实际内容。
原创2026/1/4大约 87 分钟
作为一名嵌入式软件从业者，在汽车 ECU 软件开发中编写高质量的软件架构文档是确保项目成功和符合行业标准（如 ASPICE 与 ISO 26262）的关键步骤。本文将从实践操作、标准要求、方法论与最佳实践等角度，详细讲解如何在软件架构设计阶段（ASPICE SWE.2）撰写一份系统架构文档。
1. 实操手册：架构文档结构与编写指南
在软件架构设计阶段，产出物是一份详细的软件架构设计文档。该文档用于描述ECU软件的整体结构、模块组成、接口关系和动态行为等，为后续详细设计和实现提供蓝图。下面提供一个标准的软件架构文档章节结构以及各章节编写要点，帮助您快速上手撰写：
原创2026/1/3大约 73 分钟