SASETalk | Z生代工程师的「立体化」安全实践
“SASETalk”是磐时打造的深度访谈栏目，通过与企业内资深技术专家对话，记录他们亲历的技术历程与行业观察，从个人视角解读行业发展变迁，共同探讨未来技术趋势与工程师成长路径。
本期嘉宾PROFILE
朱利亚
磐时 功能安全工程师
熟悉ISO26262、ISO21448，具有全智能主动悬架、线控制动、线控转向等系统功能安全设计与认证经验。精通 Carsim+Simulink 仿真、STPA / HAZOP 分析，熟练运用 CANOE / Medini 等工具，掌握 Autosar / EGAS 架构；持有 AFSP 证书，参与国标 / 团标 / 知名OEM企标制定，主负责 ASIL B-D 多等级项目认证。
01
在量产节奏下的方法论养成
从计算机专业毕业，到迅速深度参与多个ASIL B/C/D高安全等级的量产项目，你认为知识结构中哪一部分帮助了你最快地完成了从学生到工程师的转型？最大的认知冲击是什么？
1. 帮助最大的知识结构：系统思维与嵌入式软硬件基础
我认为帮助最大的知识结构并非单一课程，而是计算机专业底层建立的“系统思维”以及对嵌入式系统软硬件协同工作的理解。
在学校里，我们学习操作系统、计算机组成原理、编译原理、数据结构等，这些知识构建了一个关于“系统如何运行”的完整图景。转型到功能安全，特别是涉及智驾、底盘这类高安全等级的系统时，本质上是在分析这个复杂系统在遭遇随机硬件失效或系统性故障时，是否会伤害到人。
从软件层面来讲：理解任务的优先级、资源竞争、堆栈溢出、内存保护等概念，让我能快速看懂软件架构文档中的安全机制（如内存分区、时间/逻辑监控），并理解它们为何能防止软件层面的失效。
从硬件层面来讲：对微控制器（MCU）/片上系统（SoC）架构的了解（如CPU核心、锁步核、内存保护单元（MPU）/内存管理单元（MMU）、时钟、看门狗等），让我能理解硬件安全机制（如锁步比较、ECC校验、内置自检（BIST））是如何检测并控制硬件随机失效的。
2.最大的认知冲击：从“功能正确”到“安全可控”的思维转变
在学校时，我们评价一个程序或系统好坏的标准，通常是“功能是否正确”以及“性能是否高效”。我们追求的是在输入正确时，输出预期的结果。
进入功能安全领域后，最大的认知冲击来自于：我们不再只关注“它应该做什么”，而开始用极大的精力关注“它不该做什么”以及“当它坏了会发生什么”。
我们需要思考：如果传感器短路了怎么办？如果软件跑飞了怎么办？这种对失效模式的思考，其实是对思维方式的一次彻底重塑。
因此，在成为一名汽车功能安全工程师后，重塑了我对“确定性”的重新理解： 计算机试图构建一个确定性的逻辑世界，但在真实的物理世界中，硬件是会随机失效的，电子噪声是存在的。我开始意识到，真正的工程挑战，是在这个充满不确定性的物理世界中，通过设计（安全机制）来构建一个让用户可接受的“确定性”安全环境。
02
融合前沿的思考与实践
你负责过与智驾、车身、地盘等多个域的Fusa需求对接。在沟通中，你觉得最大壁垒是技术语言的差异，还是开发节奏和优先级的不同？作为安全方，如何推动并“说服”其他团队？
1. 最大的壁垒：开发节奏和优先级的不同
技术语言的差异确实是存在的，但它更像是一道可以通过学习来跨越的鸿沟，而非真正的“壁垒”。比如说智驾的同事讲感知、融合、规控；底盘的同事讲制动压力、转向扭矩；车身的同事讲门窗、灯光逻辑。这确实需要我花时间去了解每个领域的基础知识，理解他们的术语。
开发节奏和优先级的不同，对于我来说才是真正的壁垒。对于研发工程师而言，他们的首要任务是“实现功能”并“按时交付”。功能安全的输入，常常被视为“额外的约束”、“增加代码量”、“影响性能”甚至“可能延误项目进度”的工作。在项目冲刺的关键节点，安全需求的优先级很容易被排在实现核心功能和修复关键Bug之后。这种由不同目标导向产生的优先级冲突，是沟通中最难调和的。
2.从 “硬件安全” 到 “软件定义安全”
作为安全方，我们的角色，并不是站在他们对面的“监督者”，而是共同为产品负责的“协作者”。我的做法是“翻译、理解、提供安全价值”：
翻译（如何传播功能安全文化）
对于研发工程师来说，他们可能无法在短时间内直接深刻的了解ISO 26262这些文字性的条款。因此，作为功能安全工程师，我会把这些需求“翻译”成他们能听懂的技术语言。例如，对底盘工程师，我会解释：“如果转向系统的角度信号因为硬件故障而跳变，在高速上可能会导致车辆突然转向，这是可能危及驾驶员及行人的生命健康安全的。我们现在讨论的这个监控机制，就是为了检测这种故障，并在发生时让系统安全地降级，保护人的安全。”当他们理解这个需求背后的“保命”逻辑时，接受度会高很多。
理解（如何去协作和寻找最优解）
我会尝试理解不同协作者的开发节奏和压力。在提出安全需求时，我会同时与他们商讨有没有更轻量级但依然有效的实现方式；或者分阶段实施，先保证核心安全机制落地。我们的共同目标是去寻找在性能、成本、进度和安全之间的最佳平衡点。这会让对方觉得我是来帮他们解决问题的，共同为了实现产品落地而服务的。
安全价值（如何进行安全的“赋能”）
功能安全不是枷锁，而是“入场券”和“护城河”。特别是在智驾领域，高功能安全等级是赢得客户信任、满足法规要求、走向更高级别自动驾驶的基础。我们做的工作，不是让他们的代码更难写，而是让他们的作品能真正安全地驶入千家万户。而这些是我们需要跟不同团队传达的安全价值。
03
下一个跨越
面以你近距离观察，当前年轻一代工程师在理解和实践功能安全时，与前辈们相比，最大的优势与最普遍的误区分别是什么？
1. 最大的优势：数字化原住民的信息敏锐度与工具思维
信息获取与整合能力强：年轻一代是互联网原住民，他们习惯于在GitHub、技术论坛、知乎、B站上寻找答案。当遇到一个陌生的安全概念或技术问题时，他们能快速通过多渠道获取信息、进行对比和学习，自学效率通常很高。
对新技术的接受度更高：例如对于AI在自动驾驶中的应用、对于SOA架构下的功能安全挑战、对于网络安全与功能安全的融合等新兴领域，年轻工程师通常有更强的探索欲和学习热情。
2. 安全验证对象扩展：从确定性系统到非确定性AI
对于缺乏经验的年轻工程师，容易将ISO 26262视为可机械套用的操作手册。在面对工程问题时，既要检索标准条款，也要分析系统具体风险；关于产品安全落地的焦点是“是否符合标准”，也是“设计是否真正安全”。
比如，缺乏剪裁能力。不敢根据实际情况对标准要求进行合理增删，倾向“多做比少做安全”，导致低ASIL系统过度设计、成本攀升，或在不必要环节机械执行造成资源浪费。对新场景应变不足。当标准滞后于技术发展时，习惯等待标准更新，而非运用标准思维方法自主构建论证逻辑，缺乏将通用原则迁移至新领域的能力。
而产生这样误区的本质，是年轻工程师混淆了“合规”与“安全”。标准是基于历史经验的通用框架，而非针对具体系统的精确解。真正的安全需要在标准框架基础上，结合具体系统的特性进行深度分析与权衡。合规不等于安全。
总结来说，我们的思维需要从“标准要求什么”转向“系统需要什么”；通过真实事故复盘建立失效认知；在标准未覆盖领域自主构建安全论证逻辑。目标是从“合规执行者”转变为“安全工程师”。
