SASETalk | 跨越二十二载，亲历汽车安全的广度与深度

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

本期嘉宾：张海艳

资深功能安全专家、智能汽车安全架构师

拥有22年汽车行业经验，完整经历了从传统发动机电控到智能驾驶中央计算的技术代际跃迁，兼具OEM、国际Tier1的全产业链视角，具备功能安全、网络安全、预期功能安全、ASPICE、SOA架构的多领域融合能力。

二十二年的宽度与厚度

Q1：您的职业生涯始于柴油机性能开发，如今深度参与新能源汽车中央大脑的SOA架构设计。这22年间，您认为汽车"安全"的内涵发生了怎样本质的变化？

我2002年入行，从柴油机性能开发做起，到今天做智能驾驶中央计算平台的功能安全架构，恰好完整经历了汽车安全在国内的演进。

第一阶段是"被动安全"。那个阶段谈安全，更多是强调上车一定要系好安全带，汽车碰撞后安全气囊能及时弹出保护司机和乘客。电子系统的安全还没有独立的概念。

第二阶段是**"电子系统安全"**，2007年我在德国大陆汽车开始深度参与柴油机高压共轨喷射的功能安全开发，系统学习了EGAS三层功能安全架构，之后在2011年迎来了第一版的ISO26262 标准，正式进入安全的体系化时期。这个阶段的标志性变化是：安全从"经验驱动"走向"标准驱动"------ISO 26262 提供了一套完整的工程方法论：HARA、ASIL 等级、安全目标分解、安全机制、诊断覆盖率、PMHF......安全第一次有了量化的框架和可审计的流程。安全不再是某个工程师的经验判断，而是一套可重复、可验证的工程活动。

第三阶段就是当下**"智能驾驶时代的多维安全"**。到吉利之后，我做极氪智能驾驶的安全架构，明显感受到安全的边界在快速扩张：

• 从关注"系统失效"扩展到关注"功能不足"------SOTIF 进入视野；

• 从关注"随机失效"扩展到关注"人为攻击"------网络安全 ISO 21434 成为必选项；

• 从关注"单点安全"扩展到关注"系统级安全"------SOA 架构下，安全机制跨域部署、跨芯片协同。

安全的维度从功能安全扩展为功能安全+预期功能安全+网络安全的多维度体系；安全的责任从单一的零部件级上升到系统级和整车级。对安全工程师的要求越来越高，做好汽车安全，需要懂架构、懂系统、懂整车、懂流程、懂管理、懂芯片、懂硬件、懂软件、懂工具。一个工程师很难做到一切都懂，这就需要大家一起合作，共同推动汽车安全事业。

您先后在多家Tier 1和OEM担任关键角色。这种"甲乙方"身份的切换，是否让您对产业链各方在安全责任、能力短板、协作痛点上有不同的见解？

我在 Tier 1 工作了约13年，在 OEM 工作了4年多，这种身份切换确实让我对产业链的安全协作有了比较完整的观察。

先说安全责任的认知差异。在 Tier 1 的时候，安全责任的边界相对清晰------按照客户给出的安全需求（FSR或TSR），交付满足 ASIL 等级的 ECU 或系统，通过 DIA（开发接口协议）明确双方的接口和责任划分。

Tier 1 关注的是"我的产品是否满足安全要求"，是一个点的问题。到了 OEM 之后，安全责任变成了面和体的问题------你要对整车的安全目标负责，要把安全目标从整车层分解到各个域、各个系统、各个供应商，还要确保分解后的安全需求能够闭环验证。

OEM 面对的不是一个产品的安全，而是整车安全论证能不能自洽。

再说能力短板。Tier 1 和Tier 2（比如芯片供应商）的短板主要在系统视野不足 。很多 Tier 1 的安全工程师对自己负责的 ECU 很熟，但对整车的安全目标、自己负责的ECU和其他系统的安全交互理解不够深入。OEM 的短板则更多体现在安全体系的工程化落地能力，即对硬件和软件开发缺乏理解。

另外，智能驾驶时代的安全涉及算法、感知、传感器融合等新领域，OEM 内部的安全团队往往缺乏这些领域的技术深度。

协作痛点方面，最突出的是安全需求的传递，OEM传递给供应商的安全需求到底应该写到多细？行业没有统一标尺，标准只说需求可测试。 OEM和Tier 1 理解完全不一样，OEM希望越粗越省事儿，Tier 1 希望越细越好，这就是协作的第一大痛点。

亲历智能汽车安全的大考

您在OEM深度参与了多个标杆级智能驾驶项目、全新SOA平台开发以及L3准入相关的SOTIF体系建设。我们想听听您对当下智能汽车安全实战的独家观察？

从这些实战项目中，我有几个比较明确的观察：

**第一，安全架构的系统性复杂度显著提升。**传统分布式架构下，功能安全基本是"纵向"的------每个功能域自己做自己的安全分析、自己部署安全机制。但到了中央计算 + 区域控制的 SOA 架构下，安全变成了"横向+纵向"的立体问题。一个安全目标涉及传感器的感知、中央计算单元的决策、区域控制器的执行、跨芯片的安全监控、跨域的降级策略

这带来的直接挑战是：安全机制的部署不再是某个域内部的事，而是需要在整车架构层面做系统性的设计。哪些安全机制放在中央计算单元、哪些放在区域控制器、哪些需要两者协同，这些决策直接影响安全架构的经济性和可靠性。

第二，供应商安全管理，智驾域涉及的供应商数量和种类远超传统域------中央计算单元、激光雷达、毫米波雷达、摄像头、超声波雷达、HOD、定位模块......每个供应商的功能安全能力参差不齐。

如何建立一套有效的供应商安全能力评估和监控机制，不是签了 DIA 就万事大吉了，你得有能力判断供应商的安全分析做得对不对、安全机制够不够、测试验证充不充分。这对 OEM 的安全团队提出了很高的技术要求。

第三，功能安全、预期功能安全、AI安全、网络安全和质量管理流程的协同是当前的一个突出薄弱点。很多公司可以独立开展任一标准的活动，但是几乎很少有企业能真正实现所有汽车安全体系的融合协同。

您参与过智能驾驶L3准入的SOTIF体系建设和开发。与功能安全相比，SOTIF的落地难点在哪里？在处理"传感器性能不足、算法局限性、人机交互误用"这些问题时，您觉得行业目前最大的认知误区是什么？

和功能安全相比，SOTIF 的落地难度确实更大，具体来说，落地难点主要在三个层面：

**第一，场景覆盖的方法论还不成熟。**功能安全的分析对象是故障模式，故障模式是有限的、可枚举的。但 SOTIF 的分析对象是场景，场景理论上是无限的。你怎么证明你覆盖了足够多的场景？行业现在的做法是"已知场景+未知场景"的两维框架------已知的通过场景库和仿真覆盖，未知的通过路测数据和边缘案例挖掘来逼近。但"逼近到什么程度算够"，这个问题没有客观答案。

我在项目中的体会是：场景的结构化梳理比单纯追求数量更重要。先把场景的维度定义清楚------道路类型、交通参与者、天气光照、自车状态、周边目标行为......然后在每个维度上做系统性的覆盖分析，这样才能避免"东一榔头西一棒子"的场景堆砌。

**第二，量化指标的缺失。**功能安全有 SPFM、LFM、PMHF 这些量化指标，虽然计算方法有争议，但至少有一个相对统一的衡量标准。SOTIF 呢？"可接受的残余风险"到底是多少？是每百万公里多少次危险事件？还是基于场景覆盖率的统计推断？行业还在探索，不同车企、不同项目的做法差异很大。

这带来的实际问题是：SOTIF 工作做到什么程度算"做到位了"，缺乏明确的判据。很多项目的 SOTIF 最后变成了"做到项目时间不够了就停"，而不是"做到风险可接受了才停"。

**第三，组织和人才的挑战。**功能安全工程师的背景通常是电子电气、嵌入式软件、质量体系。但 SOTIF 需要的能力模型完全不同------你得懂算法、懂感知、懂传感器性能、懂场景定义、懂人机交互。这些知识很多不在传统功能安全工程师的知识体系里。

您同时精通功能安全、网络安全、SOTIF和ASPICE。在真实项目中，这四个体系是各自为政，还是可以有机协同？

这四个体系，我在实际项目中都有接触。

我的判断是：它们在理论上应该协同、在工程上可以协同，但在大多数组织中确实是各自为政的。安全措施分别设计，文档臃肿，流程厚重跨标准风险遗漏，评审与审计工作量大，人力成本高企。

协同的关键在三个层面：

第一，流程层面的协同------ASPICE 是粘合剂也是过程。很多人把 ASPICE 理解成"一堆流程文档"，但我更愿意把它看作一套工程过程的基础框架------需求管理、架构设计、软件实现、集成测试、验证确认......这些过程是功能安全、网络安全、SOTIF 都需要的。好的做法是：建立一套基于 ASPICE 的基础工程过程，然后在各个过程节点上叠加不同安全标准的特定要求。而不是每个标准各建一套流程，那样团队的流程负担会非常重。

**第二，架构层面的协同。**不管是功能安全、网络安全还是 SOTIF，最终都要落到系统架构上。我的做法是：在架构设计阶段，就建立一个统一的"安全架构视图"------把功能安全的安全机制、网络安全的安全措施、SOTIF 的改进策略，都映射到同一个架构框架下。这样哪些地方有重叠、哪些地方有缺口、哪些地方需要协同设计，一目了然。

**第三，需求层面的协同。**安全需求不应该按"功能安全需求""网络安全需求""SOTIF 需求"分成三张独立的列表，而应该在系统需求层进行整合------同一个系统元素，它的安全需求是多维度的，要放在一起管理、一起追踪。

协同最大的障碍往往不是技术，而是组织。功能安全团队、网络安全团队、质量团队，可能分属不同的部门，汇报线不同、KPI 不同。要真正实现协同，组织上必须有一个高层级的安全总负责人，能够跨部门协调资源、统一安全策略。否则协同只能停留在口号上。

行业价值的沉淀与转化

您既在顶尖Tier 1主导过量产，又在头部OEM经历过自研攻坚。基于这种经历，您认为当下国内车企和供应商在功能安全能力建设上，最普遍的"短板"是什么？是流程、技术，还是组织文化

对于 Tier 1，最普遍的短板是安全分析的工程深度不足。国内很多 Tier 1 的功能安全还停留在"文档合规"层面------为了过认证、为了满足客户要求，做了一堆安全分析文档，但这些分析有没有真正指导设计、有没有真正发现问题，要打个问号。

常见的现象是：FMEA 做了，但严重度、发生度、探测度的打分很随意；FTA 画了，但底事件的失效率数据是拍脑袋的；安全需求分解了，但没有真正追踪到设计实现。

对于 OEM，最普遍的短板是安全架构能力和整车级安全论证能力。智驾域的功能安全架构设计------包括相关项定义、HARA 分析、FSR 向各关联域（智能座舱、底盘、动力、车身）的分配、和子系统工程师对接落地策略（比如动力域加速度限值、底盘减速度限值）。这些工作需要既懂功能安全方法、又懂整车系统架构的人来做，而这样的人在行业里是稀缺的。

如果要说一个最根本、最普遍的短板，不分 OEM 和 Tier 1，那就是：安全没有真正融入工程文化。

什么叫融入工程文化？就是系统工程师在做架构设计的时候，自然而然会考虑架构的安全合理性；软件工程师在写代码的时候，自然而然会考虑代码的安全鲁棒性；测试工程师在写用例的时候，自然而然会考虑安全需求的验证。

但现在很多公司的状态是：安全是安全团队的事，开发团队觉得安全是额外的负担。安全团队和开发团队之间是"审核与被审核"的关系，而不是"协作与赋能"的关系。

这个问题的解决不能靠安全团队自己努力，它需要管理层真正把安全放在战略位置上------不是口头上的重视，而是在组织架构、资源配置、考核机制上体现出来。

在您看来，磐时咨询最吸引您的地方是什么？是平台的技术视野、专家网络，还是服务客户的方式？能为客户和行业带来什么价值？

**磐时最吸引我的地方，是它的专家平台模式------不是先拿项目再找人，而是先聚集了一批有真才实学的行业专家，再用专家的能力去服务客户。**这个逻辑和传统的咨询公司或服务公司是反过来的。

具体来说，有三点我比较认同：

**第一，技术的广度和深度并重。**磐时的专家网络覆盖了功能安全、网络安全、SOTIF、ASPICE、SOA 架构、自动驾驶等多个领域，而且每个人都是从一线实战中走出来的，不是纯理论派。

汽车安全发展到今天，单一领域的专家已经不够用了------一个智能驾驶项目，你得同时懂功能安全、网安、SOTIF、软件架构，才能把问题看清楚。磐时这种多领域专家协同的模式，正好对应了行业的这个趋势。

**第二，服务理念是"赋能"而非"外包"。**我接触过很多咨询项目，模式是"客户出钱、咨询公司出报告"，报告交了项目就结束了，客户自己还是不会做。磐时的做法不一样------是和客户的团队一起工作，在做项目的过程中把方法和能力传递过去。我觉得这才是咨询真正的价值：不是替客户解决一个问题，而是帮客户建立解决一类问题的能力。

**第三，对行业价值的长期主义取向。**汽车安全这个领域，短期利益和长期价值经常是矛盾的------你可以靠打价格战拿项目，但那样做出来的东西对行业没有价值。磐时选择的是另一条路：做标准研究、做行业培训、做技术沉淀。我认同这种长期主义的取向。

至于能为客户带来什么价值，我认为核心是"加速能力建设、降低试错成本"。汽车安全是一个踩坑成本很高的领域------一个安全架构的失误，可能要到量产之后才暴露，召回成本动辄上亿。

磐时的专家都是在行业里摸爬滚打了十几年、几十年的人，该踩的坑都踩过、该趟的路都趟过。我们能帮客户在更短的时间内、以更低的试错成本，建立起真正有效的安全能力。这对正在快速转型的国内车企来说，我觉得是有实实在在的价值的。

对于有志于成为下一代汽车安全专家的年轻人，如果他们无法复制您这样"跨越二十二载"的经历，您建议他们应重点构建哪两到三个核心能力？

如果只能选三个，我会选：系统思维能力、跨领域融合能力、工程落地能力。

第一，系统思维能力------这是安身立命之本。汽车安全做到深处，拼的不是你对标准条款背得有多熟，而是你能不能从系统层面看问题。一个故障从底层硬件传到上层应用，路径是什么？一个安全机制部署下去，对其他功能有什么影响？一个安全需求从整车分解到软件单元，中间的论证链能不能闭环？这些都是系统思维的问题。

怎么培养？我的建议是：不要只钻在安全这一个领域里，要主动去了解系统、了解软件、了解硬件、了解整车。我自己的路径其实也是这样的------从柴油机性能开发做起，到电子燃油喷射系统，到软件，到功能安全，再到智驾架构。知识面越宽，系统思维的根基就越扎实。

具体的做法可以是：主动参与系统架构评审、主动去理解你负责的安全功能在整车中的位置和作用、主动和不同领域的工程师交流。不要等别人来给你讲，要自己去挖。

第二，跨领域融合能力------这是面向未来的核心竞争力。传统的功能安全工程师，可能只需要懂 ISO 26262 就够了。但未来的汽车安全专家，必须能够把功能安全、网络安全、SOTIF、AI 安全这些维度串起来。为什么？因为未来的汽车是软件定义的、是智能的、是连网的------安全问题是交织在一起的，你不可能只解决一个维度的问题。

我自己也是在不断拓展边界------从功能安全到 ASPICE，从 ASPICE 到网络安全，从网络安全到 SOTIF，从 SOTIF 到 SOA 架构。

这个过程不是一蹴而就的，是一个持续学习的过程。但方向是明确的：T 型人才------在一个领域有深度，同时在相关领域有广度。

第三，工程落地能力------这是区分"理论家"和"实战派"的关键。汽车安全不是纸上谈兵的学科。标准读得再熟、分析做得再漂亮，如果不能指导工程实践、不能解决实际问题，那就是空中楼阁。我见过不少安全工程师，讲起标准来头头是道，但一到具体项目里，就不知道怎么把标准要求转化为可执行的工程活动。

怎么培养工程落地能力？去项目里摸爬滚打，去一线解决实际问题。不要只待在办公室里写文档，要去和开发团队一起做设计、和测试团队一起做验证、和供应商一起做技术评审。在这个过程中，你会发现标准里没有答案的问题、书本上没有遇到过的挑战------解决这些问题的过程，就是工程落地能力成长的过程。

关于我们：

在汽车电子电气架构向集中式演进的背景下，功能安全不仅是一套合规流程，更是关乎整车软硬件协同与量产可靠性的系统工程。对企业而言，真正的痛点在于如何摆脱"为了拿证书而做文档"的浅层合规，将安全要求扎实落实到架构设计与工程实践中。

磐时深耕汽车功能安全领域，围绕 ISO 26262 为客户提供从体系搭建到工程服务的一站式解决方案。

从概念阶段的 HARA 分析与安全目标分解，到集中式架构下的跨域安全机制设计、系统级 FMEA/FTA/FMEDA 深度分析，再到协同ASPICE与预期功能安全的一体化落地，磐时致力于以一线实战专家的深度工程经验赋能客户，助力企业建立真正自主可控、融入研发基因的安全能力。