SASETalk | 从车辆工程到ASIL D芯片安全：一位年轻工程师的成长进化论

“SASETalk”是磐时打造的深度访谈栏目，通过与企业内资深技术专家对话，记录他们亲历的技术历程与行业观察，从个人视角解读行业发展变迁，共同探讨未来技术趋势与工程师成长路径。

本期嘉宾PROFILE

王茁轩

功能安全工程师

3年芯片功能安全经验

熟悉ISO26262、IEC62380、IEC61709、SN29500；拥有ASIL D产品开发经验；熟知芯片开发验证封装测试流程，熟练掌握SEooC，硬件（系统）架构设计，HSR，安全分析（HW/SYS-FMEA，DFA，FTA），FMEDA等方法和相关工具的应用。拥有FSPA汽车功能安全职业证书。

01

安全意识的“第一课”

您行业初印象：从车辆工程专业毕业时，功能安全对你而言是课本上的概念还是清晰的职业方向？入职后接触的第一个具体任务与你最初的想象有何不同？

功能安全是我在求职过程中才了解到的概念，之前也学习过汽车的主动、被动安全设计，所以功能安全更像是一个既熟悉又陌生的边界线。在车辆工程的本科课程中，我们更多学习的是汽车的正向功能——发动机如何工作、底盘如何操控、CAN总线如何通信。虽然当时也接触了ISO 26262或者一些可靠性工程的基础知识，但在毕业时，功能安全确实还停留在书本里一个“章节”或“名词解释”的层面。它被简单地理解为“不要出故障”，或者直接等同于“双系统冗余”，并没有形成一个完整的职业画像。

真正让我觉得这可能是一个清晰方向，是在毕业设计期间接触到一些关于线控转向的论文时。我突然意识到，随着电子电气系统越来越复杂，软件代码越来越多，传统机械的物理失效已经不是唯一的风险了，“系统性失效”和“未知的未知风险”开始成为难题。当时隐约觉得，这背后一定有一套严密的逻辑和规则去约束这些看不见的风险，而这套规则或许就是未来汽车行业的基石。所以，它不是一蹴而就的清晰职业路标，但确实是让我觉得非常值得探索的那条林间小路。

入职后，我接到的第一个任务是针对一个组合定位导航系统的电源模块进行FMEDA分析。我最初的想象中，这应该是一个非常“爽”的工作：拿到原理图，翻着标准，对着清单一个一个元器件打勾，计算它们的失效率，然后套公式，最后得出一个漂亮的数字。感觉就像是拿着标准答案去核对作业。然而，当我真正上手去做的时候，发现了三个巨大的反差：

从理想主义到拉锯战：我本以为FMEDA只是关于技术的计算，但实际上我意识到，功能安全首先是关于沟通的艺术。因为硬件工程师设计的电路未必有冗余，我在计算单点故障度量时发现某个电容失效会导致系统直接偏离安全目标。我需要拿着数据和架构去和硬件工程师辩论：是改电路，还是加诊断，或者接受风险？这和我最初想的一个人闷头做分析完全不同。

从静态计算到动态迭代：想象中的分析是线性的，但实际的FMEDA是一个反复迭代的过程。设计变一下，诊断覆盖率就要重新算；甚至发现某个失效模式其实可以被软件里的看门狗覆盖，这又需要和软件功能安全工程师确认窗口时间。这个任务就像一个巨大的拼图，需要不停地协调、确认、更新，远没有课本上那个例题那么干净利落。

对数字的敬畏感：起初看失效率数据，觉得就是个冷冰冰的数字。但真正在做FMEDA时，当把一个μC的失效率分摊到各个模块，再联系到它万一失效会让方向盘失去助力时，我真正理解了这几个小数点后面的数字，背后对应的是实实在在的风险和责任。这让我对这份工作的严谨性有了全新的敬畏。

快速学习的关键：在三年内，你从协助文档编写到主导芯片级ASIL D认证，这种快速跨越的秘诀是什么？有没有一个时刻或项目让你突然对功能安全有了“顿悟”般的理解？

刚开始协助编写文档时，很多人可能会陷入一个误区：觉得功能安全就是填表格、画流程图、套模板。但我当时做了一件比较“笨”的事：每当我接手一份前辈的文档（比如FSC技术安全概念或硬件安全需求规格书），我都会反向推导——“这个安全机制为什么要在这里？如果删掉它，底层的故障会怎么蔓延？”我把写文档的过程，变成了模拟系统失效的过程。这让我在早期就建立了一个宝贵的资产：失效模式的案例库。当后来主导芯片级认证时，我面对的虽然是一个复杂的SoC，但里面的逻辑模块（比如锁步核、ECC保护、内存保护单元）的失效逻辑，其实在系统级已经有了原型。功能安全不是孤岛，我花了很多时间去“偷师”架构师和硬件工程师的知识。当我在做FMEDA时，我不只看失效率，我会追问硬件工程师：“这个电压监控的阈值为什么设在这里？”当理解了物理设计的边界，我写出来的安全机制才是可落地的，而不是空中楼阁。这种翻译能力——把安全需求翻译成工程师听得懂的工程语言，是建立信任和推动项目的关键。

说到顿悟，它发生在主导第一个芯片级ASIL D认证项目的中期评审阶段。当时我们正在开发一款IMU芯片，按照标准，我们需要证明它对于系统级的ASIL D要求是够用的。在分析片上存储器的保护机制时，我对着几百页的芯片手册和数据流图，突然产生了一个思维的飞跃。那一刻，我没有再把这个芯片看作是一个复杂的、由逻辑门和硅材料构成的物理实体，而是把它看作是一个信息流处理的管道。我意识到，所谓芯片功能安全，本质上就是确保这个“管道”在处理任何数据（无论是指令还是信号）时，一旦发生信息被篡改、延迟或丢失（即故障），必须有且只有一条清晰的路径去发现它、遏制它、或者优雅地过渡到安全状态。在此之前，我看功能安全是看“文档完整性”、看“诊断覆盖率”、看“指标计算”。在此之后，我看功能安全是看“架构的脆弱性”、看“隔离的清晰度”。标准里的指标（SPFM，LFM，PMHF）不再是终点，而变成了验证信号链路是否被忠实执行的检查手段。

02

与最高安全等级“过招”

挑战ASIL D：从负责产品的功能安全，到深入惯导芯片本身进行ASIL D开发，这其中的技术挑战发生了怎样的本质变化？最让你“烧脑”的部分是什么？

在模组层级，我们讨论的失效往往是比较宏观的，如“CAN总线通信丢失”、“电机输出轴卡死”、“电源供电中断”。这些失效模式通常有对应的机械或电气现象，我们可以通过相对直接的诊断手段（如看门狗、回读校验、电压监控）来覆盖。而芯片层级的挑战在于，你面对的不再是一个功能模块，而是一块充满了晶体管、逻辑门和布线的硅片。如“寄存器内的一个bit位发生了翻转”，或者是“因为相邻金属线之间的耦合电容导致信号串扰”。在魔族上我们可以在产品上布置各种测试点，用万用表、示波器去测量。而对于芯片，一旦芯片封装好，里面的节点对于外界来说几乎是一个黑盒。你无法把探针伸进纳米级的工艺节点里去测量某个特定触发器的状态。

让我烧脑的核心，是在芯片微架构层面，对时间、面积、功耗与安全进行的极致权衡。在模组级如果觉得不够安全，可以放两个MCU，做双通道比对。这在成本、空间和功耗上虽然代价不小，但在系统层面是相对简单的解决方案。而在芯片里，你要在指甲盖大小的面积上，在毫瓦级的功耗预算内，实现ASIL D级别的诊断覆盖率。以惯导芯片为例： 它的核心是MEMS传感器和模拟前端。要诊断MEMS结构是否损坏，你不能加一个一模一样的备份MEMS。你需要设计巧妙的内置自检结构，通过施加静电力来模拟加速度，看读出电路的响应是否正常。这个自检不能影响正常工作，还要能检测出特定的失效模式。

工具与流程的实践者：对于一名年轻工程师，如何避免被繁杂的文档和工具淹没，而真正抓住功能安全工程的核心主线？

被文档淹没的根本原因，往往是我们把文档当成了目标，而不是手段。功能安全唯一的起点是“风险”和“最坏情况”。也就是ISO 26262里定义的那个东西——安全目标。每当我接手一个新项目，面对一堆待产的文档时，我会强迫自己停下来，只问一个问题：如果这个东西坏了，会发生什么最可怕的事情？（比如车辆失控、无法转向、非预期加速）。然后，我再逆推回来：为了防止这个最坏情况，我需要做什么？我需要定义安全状态（比如切断动力）。为了进入安全状态我们就可以开始设计监控机制及其验证方法。最后自然会形成文档。当你脑子里始终悬着那把“达摩克利斯之剑”时，你就会自动过滤掉那些与风险控制无关的细枝末节。文档不再是负担，而是你为了保护系统安全所构建的证据链。

03

读懂客户的“潜台词”

从应审到前瞻设计；在与客户（尤其是OEM）交流时，他们除了标准符合性之外，最关心什么？这些经验如何反过来影响芯片层级的设计思路？

在我接触的国内外客户中，能通过评审仅是基本的入场券，他们更多关心的是你的产品是否真的可靠、有效。比如有客户关注你的安全诊断机制的透明度，产品需清晰追溯内部异常情况，还要明确监控机制的原理。另有客户对产品假设的运行环境或外部措施有限制，这就需要你对产品的假设不能过于严格，你的安全状态设计不能过于复杂，你的接口不能过多。还有客户对产品的误报警率比较在意，因为需要在产品保证安全的同时，可用性也同样重要，毕竟不能提供一个频繁进入安全状态的产品，否则会导致大量客诉。

这就需要我们功能安全工程师在开发过程中，不能仅作为一个ISO 26262的专家，更要成为一个理解汽车商业逻辑、系统集成痛点和用户体验价值的系统架构师。我们的设计目标，不再只是通过ASIL认证，而是帮助OEM造出更可靠、更易用、更能赢得消费者信任的汽车。当芯片内部的安全机制能够直接回应OEM对于责任、可用性、易用性的关切时，功能安全就真正从合规成本转变为了产品竞争力。

04

进化

用展望未来角色

对于同样想在三五年内快速成长的年轻功能安全工程师而言，你认为最应该深耕的一两个技术领域是什么？最需要避免的“弯路”又是什么？

如果只能深耕一个技术领域，我会选择 “系统架构设计”。原因在于，功能安全工程师很容易陷入极端：对ISO 26262的条款倒背如流，但看电路图如同看天书，和硬件、软件工程师沟通时缺乏共同语言；或者是深陷于某个具体模块的FMEDA或者软件诊断的细节，却忘了这个模块在整个车里是干什么的，一旦失效会引发什么后果。所以，在三到五年的成长期，你需要建立“端到端”的视野。这意味着你要能看懂从传感器输入（感知）-> 决策算法（处理）-> 执行器动作（控制）的完整信号链。抓住 FMEA和 FTA这两个工具。不要把它们仅仅当作合规文档，而是当作理解系统的手术刀。通过做FMEA，你会逼着自己去问：“这个CAN信号如果延迟了会怎样？这个电压如果漂移了软件能识别吗？”这个过程会让你比系统工程师更懂系统，比软件工程师更懂安全机制的必要性。

说到弯路，我觉得最可惜的一种情况是：把平台的能力，错当成自己的能力。很多人入行后，看到行业里自动驾驶火了就追L3/L4，看到AI芯片火了就去研究NPU的安全。这本身没错，但如果基础还没打牢，很容易变成“空中楼阁”。比如，直接去挑战一个复杂的AI芯片的ASIL D认证，如果连最基础的锁步CPU是如何工作的、内存ECC的单比特纠错双比特检错机制到底怎么在硬件层面实现都没搞懂，那么在评审会上，面对硬件专家和架构师的提问，可能会很难应对。另外，功能安全确实涉及很多流程，但如果你在三五年内，把自己的核心竞争力定义成会走流程、会写文档，那可能会比较被动。因为流程可以被AI辅助，可以被模板化，但对失效机理的深刻理解，对系统复杂性的洞察，是机器很难替代的。

你选择加入磐时，是希望如何实现自己的下一个职业目标？期待为解决行业的哪些痛点贡献力量？

选择加入磐时，对我来说不仅仅是换一份工作，更像是一次从运动员到教练员兼战术分析师的转变。我希望在这里，既能拓宽自己技术视野的广度，又能锤炼解决深层次问题的能力。我希望利用磐时的平台优势，接触到不同客户、不同领域（从传统的动力底盘，到新兴的自动驾驶、智能座舱，甚至是跨行业的工业控制）的项目。每一个新项目都是一次快速学习的机会。我的目标是在未来几年中，积累起覆盖多个技术领域的安全模式库。当客户遇到一个棘手的失效问题时，我能迅速从脑海里调取出之前在类似场景下验证过的解决方案。

在几年的工作中，我观察到行业里普遍存在几个痛点。比如在很多企业内部，功能安全团队和研发团队是割裂的。安全工程师在造文档，研发工程师在搞开发，到最后项目评审时，才发现安全需求无法落地，或者安全机制影响了功能性能，导致大量返工。我希望利用磐时独立的第三方视角，充当一个 翻译者和融合者。我们不只带来标准，更带来业界最佳实践。通过早期的安全概念介入，帮助客户在架构设计阶段就把安全内生进去，让研发团队觉得安全是帮手，而不是“对手”。另外，很多企业的安全经验沉淀在个别的资深工程师脑子里，一旦人员流动，经验就断了。而且不同项目组之间的失败教训和成功经验很难共享。磐时作为第三方，有机会接触大量不同类型的项目。我们内部积累的失效案例库、最佳实践模式、以及各种踩坑教训，其实是我们能给客户带来的最大附加值之一。我希望能把这些跨行业的、跨领域的经验，系统化地整理和提炼，然后反哺给我们的客户，帮助他们站在我们的肩膀上，看得更远，少走弯路。